Compiling C/C++ code from Matlab on Ubuntu Linux machine

It seems that there is much easier way of compiling and running C/C++ from your Matlab application, than the one I was trying before.

Reproducing the instructions on this blog here:

My version of gcc (4.4) is too high for Matlab R2009b (4.3), and Matlab chokes on it. The solution is as follows:

Install gcc-4.3:


sudo apt-get install gcc-4.3
sudo apt-get install g++-4.3


In matlab, run mex -setup and select the GCC compiler.(Choose option 2). Next, at the command line:


sudo gedit ~/.matlab/R2009b/mexopts.sh


Replace all instances of CC=’gcc’ with CC=’gcc-4.3′, and al instances of CXX='g++' with CXX='g++-4.3'.
And restart Matlab !

Disable the graphics on your machine

Just a quick note about how to disable the graphical user interface on your machine safely and quickly. This may be useful if you are having issues with your video card causing your system to crash. By disabling the graphics you could get command line interface to your machine.. and hopefully determine the exact problem to get your GUI to work.


mv /etc/init/gdm.conf /etc/init/gdm.disabled


This works on Ubuntu 10.04 LTS.
Remember that this would disable the graphics on all your boots. Not just the the one from which you make the change. And of course run the reverse mv command and reboot your machine to start your graphics again.

How to install Xen4.0 on Ubuntu 10.04 LTS

This post provides documentation about how to get Xen4.0 (the opensouce version) up and running on an Ubuntu 10.04 LTS (Long Term Support) 64-bit machine.

Start of with a fresh new installation of Ubuntu 10.04 LTS. Install the required packages first:

apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev git-core uuid-dev ocaml libx11-dev

On a 64-bit machine, you will also need this additional package:

apt-get install gcc-multilib

The next step is to get Xen4.0.1

cd /usr/src/
wget http://bits.xensource.com/oss-xen/release/4.0.1/xen-4.0.1.tar.gz

Un-tar and make:

tar xf xen-4.0.1.tar.gz
cd xen-4.0.1
make xen
make tools
make stubdom

At this point you should have the Xen hypervisor/tools binaries in "dist/" directory ready for installation. Now run:

make install-xen
make install-tools
make install-stubdom


The next step is to download and compile a dom0 kernel, and to update the grub file. We can do this using the following commands:

make prep-kernels


This will create a build-linux-2.6-pvops_x86_64 directory in /usr/src/ which has by a .config file in it. You need to modify the .config file to suit your requirements. You can have a look at mine here. (Source Boris Derzhavets).
You could use make menuconfig from inside the build-linux-2.6-pvops_x86_64 to make alterations to your .config file.

cd build-linux-2.6-pvops_x86_64
make menuconfig
make
chmod g-s /usr/src/ -R
make deb-pkg
dpkg -i ../linux-image-2.6.32.21-xen_*.deb
depmod 2.6.32.21-xen
update-initramfs -c -k 2.6.32.21-xen


At this point enable Xend at boot:

update-rc.d xend defaults 20 21
update-rc.d xendomains defaults 21 20


When I typed in the last two lines, I got warning messages saying:

update-rc.d: warning: xend start runlevel arguments (2 3 4 5) do not match LSB
Default-Start values (3 4 5)
update-rc.d: warning: xend stop runlevel arguments (0 1 6) do not match LSB
Default-Stop values (0 1 2 6)


Apparently these messages are benign and should not cause any issues in the working of Xen Daemon. Now create the Grub2 entry for your new kernel:

vim /etc/grub.d/40_custom


Following is what I entered to in the 40_custom file. My installation still has issues because the graphics driver keeps crashing, and I think that the grub file has something to do with it.

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.

menuentry 'Xen 4.0.1, Ubuntu 10.4 kernel 2.6.32.21' {
recordfail
insmod ext2
set root='(hd0,1)'
multiboot (hd0,1)/boot/xen-4.0.1.gz dummy=dummy dom0_mem=832M
module (hd0,1)/boot/vmlinuz-2.6.32.21-xen dummy=dummy root=/dev/sda1 nopat ro nomodeset console=tty0 earlyprintk=xen
module (hd0,1)/boot/initrd.img-2.6.32.21-xen
}


Update grub and reboot... And choose the correct grub option from the boot-up menu.

update-grub
reboot


Compile glxgears from source on Ubuntu 9.10

I decided to modify the source code of glxgears to overcome a peculiar problem. This application would not write the FPS information to file (if redirected) unless it is shutdown.

I checked the source code, glxgears.c and found the problem was simply that there was no fflush statement after the output printf:

static void
event_loop(Display *dpy, Window win)
{

....
if (t - t0 >= 5.0) {

GLfloat seconds = t - t0;
GLfloat fps = frames / seconds;
printf("%d frames in %3.1f seconds = %6.3f FPS\n",frames, seconds,
fps); //no flushing!
t0 = t;
frames = 0;

}}}

}

And so, the solution seemed simple: add the line of code that would force the output buffer to flush (fflush(stdout);) after printf and re-compile the source code.

To be able to compile glxgears.c, however one needs to install many other libraries and packages. Here are the steps that I followed to get the whole thing working.

1. glxgears is part of the Mesa Library. I downloaded th latest source code (MesaLib-7.8.2.tar.gz)


2. Start by untarring this file:

   tar -xvf MesaLib-7.8.2.tar.gz

3. Enter the directory Mesa-7.8.2 and type: ./configure --with-driver=xlib. The configuration code will now start spitting out the libraries that it needs (and which your machine does not have). Following are the libraries that I needed on my machine:


1. libdrm:

   sudo wget http://dri.freedesktop.org/libdrm/libdrm-2.4.21.tar.gz
tar -xvf libdrm-2.4.21.tar.gz
cd libdrm-2.4.21/
./configure
make
make install


2. xorg-macros:

   wget http://mirrors.kernel.org/ubuntu/pool/main/x/xutils-dev/xutils-dev_7.5+4_i386.deb
sudo dpkg -r xutils-dev
sudo dpkg -i xutils-dev_7.5+4_i386.deb
ls /usr/share/pkgconfig/


3. dri2proto:

   wget http://xorg.freedesktop.org/releases/individual/proto/dri2proto-2.3.tar.gz
tar -xvf dri2proto-2.3.tar.gz
cd dri2proto-2.3/
./configure
make
make install


4. glproto:

   wget http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.12.tar.gz
tar -xvf glproto-1.4.12.tar.gz
cd glproto-1.4.12/
./configure
make


5. xxf86vm:

   sudo apt-get install libxxf86vm-dev

6. xdamage:

   sudo apt-get install libxdamage-dev

4. After all the dependencies are satisfied, ./configure --with-driver=xlib will complete and create the make file.


5. Follow it up with: make. Once you modify the Mesa-7.8.2/progs/xdemos/glxgears.c file, call ./configure --with-driver=xlib and make. The new glxgears executable will be created in the same directory as the souce code.




How to get Virtual Manager to work for a Xen host

So, continuing with the theme of Xen, Virtual Machine Manager or virt-manager for short, is a piece of software that I decided to check out because I wanted graphical access to my virtual machines. A more formal description as given on their website is:

"Virt-manager is a desktop user interface for managing virtual machines. It presents a summary view of running domains, their live performance & resource utilization statistics. The detailed view graphs performance & utilization over time. Wizards enable the creation of new domains, and configuration & adjustment of a domain's resource allocation & virtual hardware. An embedded VNC client viewer presents a full graphical console to the guest domain"

You need to download virt-manager on the machine from which you wish to access your virtual machines. I am using a machine running Ubuntu 10.04 which I will call the client machine in the description below.

My Virtual Machines (VMs) were created on top of Xen 3.2 hypervisor, Earlier I had some issues getting the network up and running on my VMs, the resolution of which I have described in an earlier post. My hypervisor machine which I will call my host machine is running kernel 2.6.24-24-xen.

So here is the procedure that I followed to get virt-manager to work:

1. I used the Synaptic Package Manager (System->Administration->Synaptic Package Manager to download virt-manager and all the dependencies on my client machine. Alternatively, one could also do sudo apt-get install virt-manager


2. On my host machine, I downloaded and installed libvirt-bin and ssh-askpass

   sudo apt-get install libvirt-bin

   sudo apt-get install ssh-askpass



3. Now to access the virt-manager console from my client machine I used Application->System Tools->Virtual Machine Manager


4. On my host machine, I started the libvirtd daemon:

   sudo libvirtd start



5. At this point I tried to connect to my host machine using File->Add Connection...; I chose my specific hypervisor (Xen) and Connection as Remote Tunnel over SSH (I am not sure that this is the one that I was supposed to use, but it did work, eventually!)
   
   At this point, I got the following error on a pop-up on my client machine and on the console of my host machine:

   libvir: Xen Daemon error :internal error failed to connect to xend

   After some effort, the following fix worked:

   
   
   1. Open the xend configuration file

      sudo vim /etc/xen/xend-config.sxp

   
   
   2. In my previous post I had talked about adding a temporary bridge between physical network device and the virtual TAP device. I had to let the xend daemon become aware of this. So under the line:

      (network-script network-bridge)

      I added:

      (network-script 'network-bridge netdev=tmpbridge')

      (To recall what my network device is called, I did a ifconfig. It was the one whose description contains the domain-0's IP.
   
   
   3. I was not done with this file yet. I needed to add the following line somewhere in the file:

      (xend-unix-server yes)

   
   
   4. I saved and closed the file. Restarted the host machine's network (sudo /etc/init.d/networking restart), restarted the xend daemon (sudo xend restart), and finally restarted the libvirtd daemon( sudo libvirtd start)
      

   
   Now when I tried to add the connection using the setting mentioned above, it went through, asked me for a password and I would see a table giving the details of the CPU utilization and some other statistics of my VMs. Following is a screen shot of what I can see so far:
   
   
   

Disable Sudo password prompts on Ubuntu

A simple trick to disable the sudo password prompts on Ubuntu (I have tested this on Ubuntu 9.10 Karmic Koala). A word of caution, be aware that by doing this you are sacrificing the security that sudo provides.

You basically need to edit the /etc/sudoers file. This file cannot be changed by any user. You need to sign in as root and then use the visudo command to start editing the file.

user@machine:~$ sudo su

[sudo] password for user:

root@machine:/home/user# visudo

In this file, right at the bottom you will find a line:

%admin ALL=(ALL) ALL

Replace it with:

%admin ALL=NOPASSWD: ALL

This will disable the requirement to enter the password every time you run a sudo command. Save and close (ESC, :wq, ENTER)

So you can now run a command like sudo reboot without having to enter the password:

user@machine:~$ sudo reboot

Broadcast message from user@machine

(/dev/pts/0) at 11:17 ...

The system is going down for reboot NOW!

Again, be careful and know what you are doing. Also, it might be a good idea to make a copy of your /etc/sudoers file before your make any changes to it.

One way to use this trick could be in a scenario where you want to run a sudo command through a script and do not want to use the -S option of sudo (-S option allows you to provide the password from the script itself; this can be dangerous if someone gets access to your script)

Add commands to bash

This post is about adding user defined commands to bash so that you can run applications only using the command rather than specifying the whole path of the application executable.

The code provided here has been tested on Ubuntu 9.10 (Karmic Koala).

There are two ways to accomplish the mission, the first is to put your application is the default path that bash already looks into while trying to execute your command, and the second is to add another location as a path that bash must check.

For the first option, run $PATH in the terminal. Your terminal output would look something like

bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

If you put your scripts/executables in any of the above locations, bash will find it and execute it without you having to specify the whole path.

For the second option, you need to edit the ~/.bashrc file and add the location of the executable to the PATH locations. Suppose this location is /home/pbhat/bin/. Concatenate the following line to the end of ~/.bashrc file.

PATH=$PATH:/home/pbhat/bin

export PATH

Save and close the file and now run the following command in the terminal:

source ~.bashrc

Unless you run this command the updated path will not show up.