Saturday, April 09, 2005

Finding the --work-properly option

I once worked on a sequence of projects that involved porting a fair chunk of code between a variety of different Unix variants—Solaris (both x86 and SPARC), IRIX, HP-UX, AIX and Linux. To begin with, we would tend to use the GNU toolchain because it was easily accessible and cheap, but in the end we had to use the native compilers on each system (not least because we were selling the product to the equipment manufacturers themselves, and they seem oddly biased towards their own toolchains).

Now, in general I remain impressed at how easily half a million lines of code did port between these systems. The codebase included some fairly low level code, some hacking in the internals of the X server, and some vexing C++ (this was pre-ANSI C++ by some margin)—and the record for getting it running on a new system was around two weeks.

However, every platform had some kind of gotcha in the toolchain. It would always be a different issue—on one platform it would be template instantiation, on another it would be position-dependent code, on a third it would be allowing dereferencing of a null pointer. In each case, though, it would boil down to a peculiar default behaviour of some tool in the build process—the compiler, the linker, the dynamic loader. In each case, it would also always turn out that there was an option buried in the depths of the man page that would make the tool behave sensibly (where "sensibly" here means to behave like the equivalent tool on the other four platforms).

Thus the legend of the --work-properly option was born.

The legend that whenever cc or ar or ld or ld.so or libdl.so isn't doing what it's supposed to, somewhere there's an option to make it so.

And now, as I try to get another project up and running again, the hunt is on for the --work-properly option for shared library generation.

[Edit: Nic helpfully points out that this page has some good stuff on OS X dylibs]

0 Comments:

Post a Comment

<< Home