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

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb 25, 2002, Jeff Sturm <jsturm@one-point.com> wrote:

> On 25 Feb 2002, Alexandre Oliva wrote:
>> There are a lot of small details that, when
>> added up, may turn into enough of a hassle that a lot of libtool's
>> built-in intelligence ends up having to be duplicated, and poorly.

> Isn't that happening already for libgcc_s?

Yup.  I find it quite unfortunate, if you ask me.

>> The only advantage I see for GCC in keep on using libtool is the
>> abstraction.

> But when we need a great deal of control over how the shared lib is
> built we have to get past the abstraction layer anyway.

Like what?

> Things I'd like to see (in no particular order):

> - symbol versioning (libgcj doesn't currently do this, but it could, and
> probably should).  This is platform and tool specific, and to my knowledge
> libtool doesn't provide any assistance.

It goes only as far as letting you pass flags to the linker.  It
definitely doesn't help you in any way, because symbol versioning is
very system-specific.  It definitely goes beyond the portable behavior
of libraries (static and shared), and libtool doesn't try to get into
this business.

Which means nothing, if you ask me.  The important thing is that it
doesn't get in your way to implement this feature.  Just like automake
doesn't get in your way (contrary to many's claims) when you need
custom Makefile rules that don't look like those that automake
generates by default.

> - real incremental linking (*not* convenience libraries, which are a lousy
> substitute).

Which of the definitions of incremental linking are you talking about?

> - better performance (why couldn't some rules be baked into the makefile
> rather than evaluated for each compilation?).

That's a possibility, but how much additional garbage are you willing
to tolerate in Makefiles?  When is it going to be too much?  When make
starts to run out of command-line space when trying to link libraries?
Why not go ahead and skip the overhead of the gcc driver and fold the
cc1 && as invocations into the Makefile?

Ok, perhaps I'm pushing too much.  I'm sympathetic to complains about
the performance of libtool.  It's dog slow.  I know it.  Folding stuff
into Makefiles might help, but I'm not convinced this would speed it
up significantly.  Perhaps I'm mistaken.

Anyway, IMO, the way to fix this in libtool (whether or not GCC uses
it) is to rewrite libtool in a more efficient language.  This has been
the subject of debates in the libtool mailing lists.  The main problem
with this rewrite is that any scripting language would become yet
another bootstrap requirement for libtool (currently, libtool only
depends on Bourne Shell and a small set of portable Unix utilities
approved for use in configure scripts); OTOH, any compiled language
would require a compiler capable of generating code for the build
machine, which is something for which there is no precedent in
autoconf, automake and libtool, and that is known to require some
shall I say interesting hacks in GCC to get Canadian cross builds
right.

> For libgcj, we could always fall back to static-only on targets where we
> don't know how to build shared libs.

And give up dynamic linking entirely.  Remember that libtool comes
with libltdl, a library that emulates dlopen even in the total absence
of dynamic linking.  You have to use libtool to link the executables
and tell they're going to attempt to dlopen certain libraries, but it
works, and I think it's worth it.  Of course, one can reinvent the
wheel and do it all without libtool.  But, again, is it worth it?

> For instance, libgcj assumes public data symbols are exported by
> default, which certainly isn't true on windows at least.

Are you talking of -export-dynamic or something entirely different?
Libtool makes -export-dynamic portable.  It's enough to link using
this option or the -module option, and libtool will know what you
mean.

> That sort of detail isn't hidden by libtool's abstraction.

If you're sure about this, perhaps you meant something else?

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