« Song for the Day | Main | Birth of a meme »
September 24, 2003
Libtool...
devil spawn or uncharted circle of hell?
The past few weeks have seen me arguing with making libtool operate on systems that it doesn't support. The port of libtool appeared to be easy enough that it took almost no time to complete code wise, the problem became linking (due to a crt1.o missing on the EROS system). That was the easy part.
The hard part is making other build systems that depend upon libtool to work properly. Under EROS there is no dynamic library support yet implemented for the system, so all libraries must be static (meaning bundled into the application). This causes for applications to have a much larger footprint on disk when built versus when using a dynamic library. There are arguments on both sides if this should be supported or not, but the fact remains right now that I'm rather unbiased as disk space is cheap and both should work equally well for what we're trying to do.
Unfortunately though it seems that libtool likes to automatically assume that dynamic libraries exist, which is a fact on most GNU based operating systems. I don't state all because EROS is a GNU licensed OS (as I'm sure there are others). Allow me to explain the problem at hand.
The issues with crt1.o missing have been plaguing us for months now, to the point where it causes any and all configure scripts to fail. Why? Because configure likes to build it's test functions utilizing libraries it does not need. The solution to this problem was to run configure on the linux host system, and hack the resulting makefiles into something usable by EROS. This mainly entails changing the CC variable, adding in a CPPFLAG and a LDFLAG, updating the 'ar', 'as', 'objdump', 'ranlib', and a few other pieces. It also requires to visually ensure that each Makefile builds a static library and NOT a shared library. This isn't as easy as it sounds once you start having to deal with libtool, which seems to just become a shell wrapper for standard compiler commands.
The resulting libtool files of types .la and .lo provide little help. While I can look into each, it seems more often than not, each will still produce a shared library as the end result. At first the idea was to try and use the Linux libtool to work around this. It should be able to work equally fine for both systems as long as the same compiler is being used, right? Well, sort of. The compiled objects would still be the same, but the system now thinks it has access to the libraries in use for Linux itself. This would be fine, but again EROS does not support dynamic libraries, so adding in < name random library here>.so for linking won't work.
The next step has been to try and port of libtool for use on EROS and insert it into the EROS XENV build tools. This was going just fine (it's the 8th such tool I've had the joy of starting to port) until we reached the linking phase and realized that, once again, we need crt1.o. That leaves a decision, wait until someone can figure out where our crt1.o has gone to before moving on, or try doing something really drastic and parallel like ripping out all references for libtool usage in the generated Makefiles. Being the stubborn headed fool that I am, I've opted for the latter, mainly because the former would cause a serious amount of downtime that would be hard to make up.
It seems that libtool, though, does some extra magic behind the scenes in it's linking phase that causes a hand linking to fail. While I could be doing something wrong on my end, I find it unlikely given the amount of time I've been pouring over Makefiles recently.
I'm open to any suggestions on means around this.
Posted by Dan at September 24, 2003 12:15 PM