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

[Alexandre Oliva <aoliva@redhat.com>]

On Feb 25, 2002, Richard Henderson <rth@redhat.com> wrote:

> How many people can fix problems with libtool when they occur?

Err...  Zero? :-)

Oh, you meant after they occur.  Perhaps half a person :-)

> How many people can fix problems with make when they occur?

Other than the maintainers of make?


How many people understand the implications involved with creating
libraries and linking with them such that they can be used properly in
the build tree (such that you can test before installing being assured
that you're not testing against a previously-installed version of the
library by accident) and the install tree (such that programs won't
search back in say /tmp/gcc-build, where hackers could place their
version of libgcc_s.so and escalate privileges whenever other users
use gcc)?

Libtool takes care of that, and that's *very* important.  More
important, in fact, than not requiring poor users to set
LD_LIBRARY_PATH, if you ask me.  I challenge anyone to come up with a
simple abstraction of library creation that accomplishes this and does
not turn into another barely-maintainable mess like libtool is.  In
fact, I'd love to be able to retire from this role of sole maintainer
of libtool in GCC, but I can't responsibly do this knowing that it
will introduce serious security problems in GCC.

> At present I believe the answer to the first question is "one".
> You are the only person I'm aware of that works on gcc that knows
> how to figure out what's happening when something goes wrong with
> libtool.  Note that this is immaterial to whether or not it is
> libtool that is at fault -- one must still track down the cause,
> which means understanding how libtool works.

I agree.  This is a problem.  There are 3 ways to fix it:

- getting more people to understand libtool :-)

- giving up on libtool and duplicating it poorly, probably running
  into the security problems I mentioned above

- getting some people to reimplement (relevant parts of) libtool for
  GCC such that we no longer depend on a single person

> On the other hand there are many people on this list that can 
> figure out what to do with a plain Makefile that has target
> specific fragments spliced in at configure time.

And miss some important implications of doing things `the simple way'.

> Having a single person at that sort of bottleneck is a maintainence
> problem itself.

No disagreement here.

> If you were to be hit by a bus tomorrow (providence forfend) we
> would either have to spend uncounted hours figuring out how libtool
> works, or replace it entirely.  And I suspect the later would take
> less time.

I don't disagree it would take less time.  But I pity users of
not-so-mainstream systems that will pay the price, and those of
relatively-mainstream systems that may become victims of hacking due
to search paths carelessly encoded into executables or shared
libraries that are part of GCC.

-- 
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