[OpenAFS-devel] Why I like libtool

[Russ Allbery]

We had a brief conversation a while back, in which I mentioned that it
would be nice to use libtool to build the AFS shared libraries and lots of
people looked disgusted and expressed deep loathing for everyone's
favorite exercise in Bourne shell stress testing.

One of the things that came out of that discussion was the feeling like
it's possible to just do shared libraries properly via host-specific
configuration, as is being done in the AFS tree right now.  I'm willing to
go with this, but having just finished looking at the shared library code
in the current AFS tree, I thought I'd run through all the things that are
currently broken that libtool would have helped fix.

 * Currently, the shared libraries aren't being given SONAMEs on Linux,
   or for that matter on any other ELF platform except Solaris.  That
   means that you can't version the shared libraries properly even if you
   *were* being sure to bump the version number every time you made an
   ABI change, since linking against the libraries declares a dependency
   on libafsrpc.so and libafsauthent.so without the major version.  This
   answers my question about whether it's safe to use those libraries on
   Linux.

 * We have what looks to be a perfectly usable mapfile to control symbol
   exporting on Solaris and Linux, but nothing uses it.  (At least GNU ld
   doesn't; maybe Solaris has some magic around the filename "mapfile"
   that I don't know about.)  I'm not sure why that is, but the libtool
   -export-symbols flag sure would come in handy and would mean we
   wouldn't have to duplicate work between ELF platforms and AIX.

 * I can't easily build a shared libsys or even a subset of what would go
   into libsys in the same directory as all of the sources because there
   is no easy way to compile the same *.c file into multiple *.o files
   without clobbering existing files.  (Not all compilers support -o with
   -c in the same invocation.)  libtool fixes this for me; without
   libtool, I have to use weird hacks like creating a pic subdirectory
   and then using compiler rules that cd into the subdirectory and then
   invoke the compiler on source relative to $(abssrcdir)... which I can't
   use because we're still using Autoconf 2.13, which doesn't define it.
   $(srcdir) may be relative or may be absolute, so there's no way to
   use it to refer to a different directory that doesn't break under some
   circumstance.

Furthermore, if I go off and try to fix the above, I can really only fix
them for Linux and maybe Solaris, since those are the only places I can
easily test.  I have no idea if the same code will work for, say, FreeBSD,
so I'll probably do whatever the person who did the Solaris work did and
just leave FreeBSD to deal with the default case where none of the above
is handled.

Note that OpenAFS is hardly alone; there are very few projects I've seen
that get shared libraries more right than libtool, even with as broken as
libtool is about some things.  I'm sympathetic to the "libtool is broken"
argument, but the problem is that the projects that don't use it almost
always end up even more broken.

Anyway, some of this stuff is fairly easy to fix, at least for Linux, so
I'll send off patches for that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>