Re: Get rid of libtool? [was Re: Makefile problems]

[Alexandre Oliva <aoliva at redhat dot com>]

[Catching up on a lot of old Nathan's e-mail]

On Jul  3, 2002, Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote:

> I'd rather not get rid of libtool; I'd rather improve it until it works
> right.  It's actually not a bad tool, but it has the wrong command-line
> semantics for Makefile purposes.  The *purpose* of libtool is to
> abstract away the differences in shared library generation.

Actually, it's to abstract away the differences in library generation,
be it shared or static.  That's why something like:

> x.lo: x.c x.h y.h ...
> 	libtool $(CC) -c x.c
> x.o: x.c x.h y.h ...
> 	libtool -static $(CC) -c x.c

doesn't make sense.  You're exposing the fact that there are static
and shared libraries and, in case the user configures
--disable-static, you lose.

> libhello.la: foo.lo hello.lo
> 	libtool $(LINK) -o libhello.la foo.lo hello.lo
> libhello.a: foo.o hello.o
> 	libtool $(LINK) -o libhello.a foo.o hello.o

You can do something like this, except that you'll have to use a
different filename for the non-libtool object files.  Personally, I
find it a mistake that libtool creates non-PIC object files outside
.libs.  They should be hidden, just like everything else, and it would
catch this very kind of construct, that could lead to hard-to-debug
problems in parallel makes (since make might be tempted to create
foo.o by compiling foo.c without libtool while libtool is creating
foo.o its own way).

Point is, you don't want to use the non-PIC object files from libtool
for anything else.  If you do, you're abusing the interface, and it
may break from under you any time.  libtool objects (.lo) and archives
(.la) are the only thing you should rely on.  You should pretend
everything other side effect is not there.

> Linking against uninstalled libraries:

> program-static: main.o libhello.a
> 	libtool $(LINK) -o program-static main.o libhello.a

> program-shared: main.lo libhello.la
> 	libtool $(LINK) -o program-shared main.lo libhello.la

> And again, the problem is that libtool insists on doing both at once.

Huh?  It creates only one copy of a program.  You don't have to use
libtool objects for it, and, if you use libtool libraries, libtool
will use the shared version in the build tree, if available, or the
static library otherwise.  If you want to prefer static libraries over
shared ones, link with -static (!= -all-static, for strictly static
linking).  You can do both in parallel if you wish.

> However, if this one repeated problem was fixed, encoding
> libtool-related dependencies into Makefiles would be quite
> straightforward and would work the Way It Is Supposed To.

Libtool-related dependencies can only involve .lo and .la files.  (not
counting executables that happen to be linked with libtool, those are
not libtool-related dependencies IMHO)

> It wouldn't even need to break libtool backward-compatibility, provided
> it was implemented as libtool options --only-shared and --only-static.

See --tag disable-shared and --tag disable-static in libtool CVS (or
the version used by GCC).  They do kind of what you want, except they
won't create the PIC and non-PIC versions of an object file at the
same time and, in fact, it can't be done in certain settings with
broken compilers that insist in creating object files in the current
directory.  Oh, and if you run two of these in parallel, outputting to
the same object-file abstraction file (.lo), only one of them will
win, so you don't want to do this.

> On the other hand, the better I understand Automake, the more I HATE it.
> It makes it waaay easier to generate nasty, stupid dependency problems.

?!?

> Most of the really irritating repetitive stuff which
> automake abstracts away can be better done using pattern rules

that you can't use portably anyway.

> or 'autogen' if you want to work in terrible makes

I still find automake's syntax far cleaner than autogen.  After years
looking at autogen source files (at rare occasions, I admit), I still
fail to find it beautiful :-(

> An example of this is the way *Automake* uses libtool.  Not libtool
> itself, but the way automake uses it.

What's the problem with it?  It abstracts libtool objects and archives
pretty well, and that's all there is to it anyway.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer