Gmake going in loops??

From many days, I have observed that our build sometimes goes into recursive loops and does not get out of the loop for many hours/days. I found the reason for this problem. It is about the modification time of makefile & C/C++ files. I use tar.gz which preserve file modification times and transfer that tar.gz to other systems. If those systems have different timezone, it might happen that the makefile/c/c++ files are modified in the future. Since gmake considers file modification times when running makefile, it goes in recursive loop. Simple solution is to touch the makefile/c/c++ files with future modification time using touch command.

Solaris:Make a shared library which can be executable

After many days, I got some free time to continue the work that I have done here.
In solaris, I know, by writing asm code, we can make a shared library work as an executable. So, I thought of writing a simple tool which can make necessary changes to shared library to act as an executable. First I have read cc man page to find out how to set an entry point. I found that we have to pass -e option to linker. So, I have written a test program [download] and compiled it to create a shared library. When executed it [$./libtest.so] , it gave segmentation fault and failed. It was setting entry point correctly. I have used elfdump to check whether it is setting entry point properly or not. We can see entry point with elfdump -p <executable> [e_entry value]. We can search for that entry point in ‘elfdump -s <executable> | grep <e_entry value>’. For reading the section headers, I have used the example given in elf man page. Then, I have executed that section header print program on that shared library. Then I have observed that the created shared library was not having ‘.interp’ section. ‘.interp’ contains interpreter value. After loading the file, system handles the control to interpreter, if ‘.interp’ section exists. So, at this stage, I thought of writing a program using elf/gelf library to add the interp section. But, when I read the man pages again, I saw -I option to linker to set the interp value. [By default, for executables, .interp section is created and /usr/lib/ld.so value is set. By default, For shared libraries, it wont create any interp section]. So, I have used -I option to compile my program into library. Now, entry point is correct and .interp section is also there. When executed my shared library [$./libtest.so], it executed normally without giving segmentation fault.

One more problem here is to get the command line arguments. I think, we have to write some assembly code to do that. If you want that feature, you can refer to this and this. you can download my programs here.

Do we need __PRETTY_FUNCTION__ like macros in other compilers?

You might know that GCC in addition to __func__ macro, it supports __FUNCTION__ and __PRETTY_FUNCTION__. __func__ is the predefined-macro which contains the function name in a string. It is defined in C specs, But, __FUNCTION__ and __PRETY_FUNCTION__ are extensions by GCC. __FUNCTION__ macro is same as __func__. __PRETTY_FUNCTION__ macro gives the full function declaration including parameters and return values. I tried to look for other alternatives on SUNWspro compilers and HP-C/C++ but could not find any. Then I questioned myself ‘do we need this macro while we can always get sufficient debug information with __LINE__ , __FILE__, __func__??’.  Answer is ‘No’. We can always get sufficient debug information with the macros defined in specs. More over, if we use GCC extensions in code, portability to other platforms is a big pain. BTW, VS.net compiler also has a similar pre-defined macro for getting decorated function name.