My tryst with Linux.

Playing around with my PC was a favorite activity during college. I used to try various OS’s at home .Notable were QNX (provides a host of features including a HTML browser  at a size of 1.44MB Floppy)  and  BeOS (another interesting OS which used to run OpenGL stuff which was otherwise not possible with my  440ZX Motherboard.)

During this time, I came to know of Linux from a friend. The whole idea of installing an operating system whose source code is available for users to change, sounded very attractive . Besides Linux is  based on UNIX. and I always wanted a UNIX environment at home after using SCOUnix for programing at my training institute.

But Linux was notorious for its ‘usability’ issues and installation was not quite easy.  We had to manually configure the mouse, soundcard ,and the gfx card. This was not easy as it sounds. I used to have a diary with all the device names/ model number and IRQ assignments before starting to install Linux.

The first distro I tried at my PC was RedHat 6.2, that came for free with PCQuest. LILO was quite primitve and GRUB was  still in the alpha stage at that time. So the paritions have to be made in windows using some tools like Parition Magic.  Once the partitions are made, it used to be a 1 hour wait (thats what was possible with a Pentium 350 MHz, 32MB RAM) until all software gets installed by the Anaconda installer .

Unlike current versions ,Configuration of display happens almost at the end of the installation.This was most annoying part.  I had an AGP card on my PC and there was no inbuilt support for it in the kernel.XWindows never worked fine for me and I had to work on a 640x 480 resolution.

Fastforward to 2008 and it all seems funny.   Today Linux is a name you cannot ignore and the latest edition from Canonical (Ubuntu Hardy) has an installation procedure that is ALMOST seamless, except for a couple of ENTER presses. As a popular AD from IBM shows, Tux is no more the new kid on the block .

Creating Shared Objects in Linux- A primer

Here is some information on the various nuances involved in compiling and using DSO’s in linux.

Lets assume the name of the source file is libhello.c. If we wanted to create a dynamic shared object we compile the file with the following flags.

gcc -fPIC -O2 -Wall -shared libhello.c -Wl,-soname,libhello.so.1 -o libhello.so.1.0

Meaning of the compiler switches:
-fPIC => This is a compiler option that instructs GCC to create Position Independant Code.PIC is a mandatory requirement for DSO’s.
-O2 => This specifies the level of optimisation to be used by the compiler.
-Wall => Generate all warnings.
-shared => This option instructs GCC to generate a shared object library.

-Wl => This is a compiler switch that is used to pass options to the linker .
-Wl,-soname,libhello.so.1 => this string sends the soname option to linker. The soname option sets the ‘soname’ for the shared object. The soname attribute is used by the dynamic linker at runtime to make sure the application loads the correct library.
The ‘1’ in so.1 is used as a versioning for the API’s exposed by the DSO. If we upgrade the API such that its not backward compatible anymore,we should change the number in the soname.

-o libhello.so.1.0 => generate the shared object with name as libhello.so.1.0

Symbolic links to the DSO:
After generating the so, we need to create some symbolic links.

ln -s libhello.so.1.0 libhello.so.1 ==> This link is used by the dynamic linker during runtime .
ln -s libhello.so.1.0 libhello.so ==> This link is used by the compiler when we link this shared object
as -l hello

Why should we have the so.1 and so.1.0 => The 1 in so.1 is used to version the API level changes. The extra versioning in so.1.0 is used to track any change in the DSO (this may not may not break the API compatibility).
Hence we have 2 versions.

LD_LIBRARY_PATH : Includes the directory of libhello to the LD_LIBRARY_PATH,so that the dynamic linker searches for libraries in this path.

ldconfig: The ldconfig command is used if we want to move our libraries to one of the standard system locations. This command also sets the symbolic links that we did manualy. This is a system administrator command .So ,to run this command you should login as root.

The rpath linker option:
Another important linker option used during development is the -Wl,-rpath. During development, there’s the potential problem of modifying a library that’s also used by many other programs — and you don’t want the other programs to use the `development’ library.
To resolve this, we used ld’s ‘rpath’ option, which specifies the runtime library search path of that particular program being compiled.

From gcc, you can invoke the rpath option by specifying it this way:
-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

If you use this option when building the library client program, you don’t need to bother with LD_LIBRARY_PATH other than to ensure it’s not conflicting, or using other techniques to hide the library.