my.tech.page

    In linux/solaris, we can use fgrep/grep for pattern matching in files. But one limitation with these commands is they limit their pattern matching to one line. They don’t search for the pattern in multiple lines. Then I found an open source tool, pcregrep [available as sdk also]. pcregrep provides multi-line grep. In many latest versions of linux and solaris machines, I have found this command, but they are older versions [maybe stable versions]. Older versions did not have multi-line grep functionality. So, I have downloaded its latest source and built it.

One usecase: I have function names, then I need to find out their declarations from header files. Function could be declared over many lines. This is my usecase. In this scenario, I have used pcregrep.

    In windows, there is a problem called “DLL HELL” which has been there for many years. I heard that, Vista is going to provide a complete solution to this problem. Unix guys thought about this problem long back and provided solution through “Version scripts” [First implemented in SunOS 2.5 and later also implemented in GCC and linux]. Through version scripts, we can simply maintain versions in shared libraries. When we link an application against a shared library that has versioned symbols, the application itself knows which version of each symbol it requires, and it also knows which version nodes it needs from each shared library it is linked against. Thus at runtime, the dynamic loader can make a quick check to make sure that the libraries you have linked against do in fact supply all of the version nodes that the application will need to resolve all of the dynamic symbols.

Simple version script looks like the following

	VERS_1.1 {
		 global:
			 foo1;
		 local:
			 old*;
			 original*;
			 new*;
		};
	VERS_1.2 {
		 foo2;
	} VERS_1.1;

More info on version scripts is given better in the reference links mentioned in the end.

GCC has added an extension to this and provided an excellent feature for function aliasing. We can do this by adding assember macro like the following in C code.

		__asm__(".symver old_foo,foo@VERS_1.1");
		__asm__(".symver old_foo1,foo@VERS_1.2");
		__asm__(".symver new_foo,foo@@VERS_2.0");

So, for the executables linked with VERS_1.2, a function call to foo will be redirected to  old_foo1 internally.  Similarly for executables linked with VERS_1.1,  function call to foo will be redirected internally to old_foo.

You can find more description about these at

http://people.freebsd.org/~deischen/symver/library_versioning.txt

www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/version.html

http://snipurl.com/wavf   [This original URL is too long.. so snipped it]

    Great day!! Finally I came to know, how to create a file which can act as both shared library and executable. You might not have observed it in your unix machines. In linux, execute /lib/libc.so as a command, it gives you all the version information. I have been trying to simulate the same feature in my shared libraries also. I have seen glibc source code and got to know that we have to use entry option of linker. With that knowledge, I have written a small program and tried for a complete working day, with the result ending up in Illegal instructions/ segmentation faults. Then I have just sent a mail to gcc mailing list and got the answers 1 ,2 ,3.

I am attaching a simple 5 line c program here. Commands that I have used are

# gcc -g -W -Wall -fPIC -o libtest.so -shared -Wl,-e,test1 test.c

    #./ libtest.so

    Hi dp! you finally made it

    # 

In our C program, we have to declare a char array for .interp section to hold the absolute path of the linker. In our entry function test1, after processing the logic, we should use exit() function instead of returning. I dont know the logic behind these 2 points.

In Solaris also, we can have this feature. But, I have not tried/tested it. If you are interested, you can look at this. Read the whole page and see the comment named “solaris 9 compile”.