Some thoughts on the modularization effort

[Kean Johnston]

> This however doesn't invalidate Kean's comments on libtools - namely
> that libtools may have some fundamental design flaws which may make
> it impossbile to port to some non-Linux and non-BSD platforms.
> If it's the design - not just an implementation flaw - it may
> be a lot harder for the autotool maintainers to fix.

Perhaps I should expand on the flaws as I've encountered them.
I know there are more than these few, but its 3:43AM and I'm
exhausted. I'll dig around my notes later to expand on this.

The first flaw is an understandable, but no less frustrating one.
libtool assumes that a fave-compiler -c -o filename.lo produces
one and only one output file: filename.lo. It then assumes that
the generated file can be moved around in various directories
and later linked. For example, when building both static and
dynamic, under some conditions which I can't codify right now,
objects (*.lo) end up in .libs. This assumption about single
output is mostly true, and almost univerally true for C compilers,
but anything that uses C++ is is more trouble. For example, any
project that uses C++ and templates will not work if you use
any derivative of the EDG C++ front-end, like IRIX and UnixWare
do, to name but two. This front-end produces template instantiation
files in *.ti files, and other intermediate data in *.ii. The
front-end then re-compiles objects to instantiate the templates
used. This all assumes that the objects are in the same place,
and that the source is in the same place when the object was
compiled. This falls appart then things get moved into .libs,
not to mention the fact that libtool doesnt move the *.ti and
*.ii files at all. So C++ breaks. This is not a huge issue for
X.Org I realize, becuase theres very little C++ (is MESA the
only place C++ is used?). But it is an issue.

The second flaw is that libtool doesn't support the notion of
a 'make install DESTDIR=/somewhere'. The install rule will
copy the .so and the .la to the right place, but if libtool
needs to do any form of linking, it used the *.la files from
the *installed* location, not the one specified (i.e it looks
in /usr/lib not $DESTDIR/usr/lib).

Third, libtool does arbitrary and incorrect command line
re-ordering. For example, if I do:
   $(CC) -o foo foo.o -L ../lib1 -llib1 -L../lib2 -llib2,
libtool will clump the -L flags together and then the -l flags.
THis is disasterous if you are trying to use -L to point to
a specific directory to link a library against. This breaks a
very fundamental usage of the link editor. Even worse, lets
say you lib1 was a libtool maintained library. You're building
a new version of lib1, and you're trying to link against the
new version. But you have an old version installed in /usr/lib.
libtool will pick up the liblib1.la for /usr/lib, and will
insert a -L /usr/lib into the link line!! This then thwarts
any subsequent -L options if any of the libraries found
also happen to be in /usr/lib.

Forth, and this is just a bug and not a design flaw, libtool
frequently uses $(LD) for creating shared libraries when using
$(CC) is almost always the correct thing to do. The C compiler
always knows how tolink things better than driving the link
editor manually, especially when dealing with threads, as
the compiler often has to link in alternate startup modules,
or special crt*.o files, or inject special libraries in
special places.

One final flaw, and its a biggie, is how LD_RUN_PATH is used.
The semantics of library location and loading are extremely
subtle and very frequently misunderstood. libtool would be
far better off hardcoding full library paths than relying
on LD_RUN_PATH and LD_LIBRARY_PATH. Not to mention that libraries
without full paths are a considerable security risk in any
process with elevated priveliges. Admittedly the RTLD can take
care of that, and these days most do, but using absolute paths
is a far safer way to fly. What you lose with absolute paths is
the ability to over-ride them with LD_LIBRARY_PATH, but thats
a relatively small price to pay, and of far less utility than
you'd suspect.

I've encountered a few other things along the way, some of which
were bugs, some of which were deeper design issues. I've tried
to discuss them with the libtool maintainers but my emails have
gone completely ignored, so I've given up trying and I just
keep my own hacked version of libtool lying around.

Some of these issues may have been addressed in more modern
versions of the tool. I admit its been about 6 months since I
last updated libtool, but I suspect most of them remain.

Kean

PS. I want it known that despite these issues I think libtool
does a pretty good job. I am not "dissing" the tool. I am pointing
out the issues I have encountered so that you can make informed
decisions about using it or not. Some of these issues are
completely moot on Linux/BSD platforms, partially becuase they
use the GNU compiler, partly becuase they use the GNU link editor,
and partly becuase their RTLD's are significantly different
architecturally to traditional System V RTLD's, or the RTLD
behaviour defined in the gABI.