Too much security

On a security enhanced linux system (selinux enabled OS), when you try to execute an application which links with user created libraries, you will (in all probabilities) end up with an error like below

./myapp : error while loading shared libaries :
/usr/local/lib/libmylib.so :cannot restore segment prot 
after reloc permission denied.

. There are two ways to escape this pain.

1. Kill the source of pain once and for all. Disable selinux. Open /etc/selinux/config and either comment out all lines or modify the following line as below
SELINUX=disabled. Save the file and voila, you are a killer.

2. Request selinux.

Dear Selinux,

Since I have to work with user created libraries, I request you to kindly allow me to access the same and run corresponding applications.

Thanking you,
A Poor suffering soul.

Well, not exactly like this, but something like below (for libraries in /usr/local/lib path)

find /usr/local/lib -name '*.so*' -exec chcon -t 
texrel_shlib_t {} \;

Wrong Architecture issue in Mac

I maintain a common source code base for both PPC and x86 architecture in Mac and just recompile (with different Makefiles) in both architectures. Once, I had forgotten to clean up a library archive which I had compiled in x86. So, when I tried compiling the library in PPC, I ended up with the following error.

ld: common symbols not allowed with MH_DYLIB output format with 
the -multi_module option
mymainfile.o definition of common _gsDeviceFreeMutex (size 44)
/usr/bin/libtool: internal link edit command failed

Just cleaning up the x86-compiled library archive removed the above error. And this drank few hours off my work-day. But, I ended up wiser ;-)

static linking in Mac - But when?

This is a linker part of my Makefile for compiling an app in Linux. It statically links a library which again I did.
Shared Library Generation

gcc  -shared -Wl,-soname,libmylib.so   -o libmylib.so.1.0.1 myownfile.o

App Generation

gcc -o testapp -L/usr/local/lib -L. -lmylib appfile1.o appfile2.o appfile3.o

This went fine in Linux. But, in Mac, the app generation started shouting. Yes, I have to compile it as a dylib file. And I did that too.

libtool -o libmylib.A.dylib myownfile.o -L/usr/local/lib -lotherlib

Ok. All are ready. Now, when I tried to compile it as below (similar to Linux), I was encountered with "undefined symbols", the same functions which I was linking from my dylib file. \

gcc -o testapp -L/usr/local/lib -L. -lmylib appfile1.o appfile2.o appfile3.o

aaaaaaarrggghhhhhh.

Googling led me to a startling (er... a rather novice mistake) revelation. With the above flow, the compiler will first encounter that library, see that it has no use, throw it off and then, try to link the object files. Now (and NOWWWW), it tries to solve the dependencies in the object files. Failing to solve, it shouts back at the user "LOSSEERRRRRR".... :-(

So, with the sombre face of a loser, I changed the compile script to follow the reverse pattern, ie, link the object files first and THEN, solve the dependencies, if any.

gcc -o testapp  appfile1.o appfile2.o appfile3.o -L/usr/local/lib -L. -lmylib

Voila. It works.

I did it! I did it! yeah yeah. I did it!

Calling one kernel module function in another

Say I have a LKM foo1.ko which has "my_foo1()" as the exported function. Now, another LKM foo2.ko calls this "my_foo1()". When this second LKM is compiled, it is generating a warning that "my_foo1() undefined!". Though this is just a warning, this can be avoided. How? I found it out via a forum. There are FOUR ways to remove the warning.

ONE: "insmod" foo1 before comiling foo2.

TWO: Compile both the LKMs in the same Makefile, in one shot; like below

$ cat Makefile
obj-m = foo1/foo1.o foo2/foo2.o

here:
       make -C /lib/modules/`uname -r`/build M=`pwd` modules

THREE: Starting 2.6.17, you can copy the Module.symvers generated by the compilation of foo1 to the foo2 source directory and compile foo2.

FOUR: Be a proper programmer and ignore it. It works anyway ! Why Worry :-)

Common symbol error in Mac

Multiple C files. Few global variables. A single dynamic library. Thats what I was trying to do in Mac. But, the compiler went jittery and complained

ld: common symbols not allowed with MH_DYLIB output format

. Googling taught me that I need to either initialize the global variable(s) or add "-fno-common" switch to the compiler flags. That solved the issue and I am happy "trying" to link it. Oh Yeah. Am facing another issue. Will update as soon as I find the solution. Cheerio.

loading shared libraries with gdb

While trying to validate a particular utility which uses a shared library (which again was developed by me and resides in user-specified path), gdb reported error that it was not able to find the shared library (although compiling the utility was not a problem). ldd also was not able to find the library, although i had used ldconfig -n /path/to/lib/dir and properly created the soname.

After some googling, I found that gdb was trying to use the ld.so.conf directory and its contents to search for the shared library objects. So, I added my path to /etc/ld.so.conf/ directory. After this, the shared object loaded without any complaint.

mmMmm...

A good kernel compilation link

A link which I regularly use (and reuse). Digital Hermit - Unix and Linux Solutions

Expat's little problem

While trying to parse my self-built XML file (with all possible legal standard headers), expat spit out the following error

Parse error at line XXX:
not well-formed (invalid token)

The XML file was good in all aspects, is what I had thought. Expat (ver 2.0.0) didnt think so. The bad part was that it parsed the whole file (including ending token) and THEN he gave the above error. Out of the wild, a thought struck me (yup, it happens to me too).

I opened the XML file and added a new line AFTER the last token. And Voila! it worked. Now, expat was happy. I was happy. All was well that ended (well actually, started) well. Need to report this to the developers(shud have been).

Mounting a storage media in Solaris

There always comes a time when even the smallest issue can make you look like a full blown idiot. (Not considering the fact that I am an idiot to some extent), this issue of mounting a pen-drive in solaris 8 made me look more like one. Then, fortunately with the help of Google, and my friend, we were able to solve the issue. Now wait a minute. Shouldnt that be easy. Well yes, AFTER we found the solution. Now, if you ask me to do the same in Linux, it will be as easy as asking Bush to talk nonsense. But, in Solaris 8, it became something like making PVNR laugh. Well, all is well and we ended doing something like this.

First run

devfsadm

then:

 mount -F pcfs /dev/dsk/cXtXdXsX:c /your/mountpoint 

This ought to do the trick forya. For us, it DID :-)

Now, with Solaris 9, my friend updated another sequence which ended up with a separate GUI window popping up just like a media drive.

After connecting the media drive, you need to restart the volume manager.

/etc/init.d/volmgt stop

/etc/init.d/volmgt start

The filesystem should show up in /rmdisk/unnamed (or under a specific name if found). Also, it pops up a separate GUI window with the contents of the drive. One thing though. Sometimes, it takes time to update the volume details and popup the window. So, keep cool and wait before coming to a conclusion. Now, to unmount the device, you need to

eject unnamed

to update the cache and unmount the device properly.