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

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

[Nathanael Nerode]

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.
Accordingly, you ought to be able to write

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

Unfortunately, libtool insists on doing both the static and shared
generation at once. This is a problem when writing dependencies, but it's 
one which small changes to libtool could fix.

Then, for linking:

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

Again, libtool insists on doing both at once, which makes writing
correct, non-redundant dependencies very hard.  This is still a problem
which could be fixed really easily in libtool.

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.

Pretty much the same damn thing happens with install.

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.

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

Note that with separate rules for shared and static libtool running,
and potentially separate arguments to libtool on a per-file basis, it
becomes easy to add specific shared-library options which are wanted by
a specific library, or indeed to put an entirely custom non-libtool rule
for particularly hairy cases.

If one subdirectory is always built with a particular unusual set of
requirements, it can even have its own libtool.  And it will all work
out all right.

---

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.
It does a poor job of getting dependencies right, and creates makefiles
which can't be read and are therefore hard to debug.  I don't see an
easy way of fixing most of the problems even with a complete rewrite
(although some of the functionality could be better implemented with a
few command-line enhancements to 'make'... but that's a complicated
other story).  

Most of the really irritating repetitive stuff which
automake abstracts away can be better done using pattern rules, or
'autogen' if you want to work in terrible makes.  Most of the other
stuff it abstracts away can only *be* abstracted away correctly 80% of
the time, which leads to endless problems.

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

Automake also makes massive use of Makefile macros, which are a known
and proven way to make Makefiles lots slower.

I would support any movement to dump automake; it seems to help people
create bad Makefiles.

--Nathanael

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

[Alexandre Oliva]

[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

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

[Phil Edwards]

On Thu, Feb 28, 2002 at 08:35:05AM +0100, Marc Espie wrote:
> This thing is at least one harder of magnitude LESS maintainable than
                             ^^^^^^
What a wonderful Freudian slip.

The best part is, if spoken aloud by some of my Cincinnati relatives,
it would even sound correct.  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[Alexandre Oliva]

On Feb 28, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:

> As a guy who does both, I'm only tweaking libtool VERY reluctantly.
> This thing is at least one harder of magnitude LESS maintainable than
> a Makefile, and probably more.

Certainly more.  It's a horrible mess.  I'm the first to admit it,
because I happen to know it pretty well.  I won't deny it.

What gets me annoyed is when people say `hey, let's throw all this
effort away and reinvent it poorly' or `hey, building shared libraries
properly is easy, why do I have to use this junk'.

Neither of these assertions are useful.  If people find libtool
unmaintainable, instead of criticizing it or threatening to replace
it, why don't they volunteer to re-do libtool in a more maintainable
way?  Then we'd have more people with a reasonable understanding of
this difficult business of abstracting away properties of static and
shared libraries.

But perhaps that's not what most people want.  Most people wish
creating libraries was trivial.  Well, with libtool, it is.  Without
it, you soon end up in a twisty maze of failures on all sorts of
different systems, or limit yourself to just a few OSs, for the
despair of users of the others.  And soon it is discovered that it
isn't that simple, and that there are serious problems with the simple
way of doing things, and then comes the choice of either living with
the problems or cluttering further the build system.

I agree libtool in its current implementation is not ideal.  But I'm
convinced its interface is very sane.  I'd love to have cooperation to
re-implement it properly, preferably from people interested in GCC
such that we wouldn't have to rely on me as a single point of failure.
But it's not going to be easy, just because building libraries
portably and managing their inter-dependencies is not easy.  I wish it
were, and I'd love to be proved wrong.  But I'm pretty sure I won't.

> This also comes from the fact that libtool is incredibly bloated,
> and does really, really need a complete redesign.
> The redesign will only happen if someone who cares about it does it.

I disagree.  Its design is very good (thanks Gord!).  It's the
implementation that sucks.

> All that people like me will do is say `we shun libtool because it's
> incredibly bloated and badly need a redesign, and our life is currently
> much easier without it anyways'.

Sure, let's go back to static libraries alone, then introduce shared
libstdc++ on a handful of platforms, then get to libjava and find out
that it's indeed not easy to get the multiple libraries it relies on
linked together properly.  But then it will be too late.

> I'm reasonably certain I'm alone in thinking like this. Do you want
> libtool to go on ? stop being blind to its issues.

I'm not being blind.  I do see what's going on, but there's little I
can do about it.  I can't do it all by myself, and those who are
interested in shared libraries don't appear to be interested in
helping get libtool re-implemented properly.  So what can I do? :-(

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

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

[Marc Espie]

In article <orzo1ucqjn.fsf@free.redhat.lsd.ic.unicamp.br> you write:
>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?

Maintainers, plural.   Several makes, lots of maintainers.
I've seen people here in the past who can fix bugs in make that
don't seem to be make maintainers anyways.

As a guy who does both, I'm only tweaking libtool VERY reluctantly.
This thing is at least one harder of magnitude LESS maintainable than
a Makefile, and probably more. This partly comes from the fact that it
is impossible to debug shell scripts of such a size. This also comes from
the fact that libtool is incredibly bloated, and does really, really need
a complete redesign.

The redesign will only happen if someone who cares about it does it.
All that people like me will do is say `we shun libtool because it's
incredibly bloated and badly need a redesign, and our life is currently
much easier without it anyways'.

Out of the auto-suite, I can live with automake and its quirks, I can
live with autoconf and its quirks, heck, I can live with cygnus-configure
and its quirks... and I could very well live without libtool.

Okay, this looks like highly flammable material, but think about it.
I'm reasonably certain I'm alone in thinking like this. Do you want
libtool to go on ? stop being blind to its issues.

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

[Albert Chin]

On Wed, Feb 27, 2002 at 11:02:04PM -0300, Alexandre Oliva wrote:
> On Feb 25, 2002, Richard Henderson <rth@redhat.com> wrote:
> 
> > 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

Have the libtool issues been directed to the libtool mailing list
where others are watching? Would be nice if GCC used a more recent
version of libtool from CVS.

-- 
albert chin (china@thewrittenword.com)

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

[Alexandre Oliva]

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

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

[Alexandre Oliva]

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

> On 25 Feb 2002, Alexandre Oliva wrote:
>> > - real incremental linking (*not* convenience libraries, which are a lousy
>> > substitute).
>> 
>> Which of the definitions of incremental linking are you talking about?

> ld -r

Libtool already uses this for some features; it would be nice if it
could use it for convenience libraries, as I have already suggested
before.  I didn't know it would cause problems on alpha, though.  More
complexity :-(

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

> I'm talking about the dllimport/dllexport mess.  Actually the dllexport is
> solved, I think... it's the dllimport that can't be automated by libtool.

Right.  That's why libtool requires the library/application to declare
it's DLL-compliant with an autoconf macro before it gets into the
business of creating DLLs for that library.  I heard some people have
recently got around this ugly detail of Windows DLLs, though, but I've
been too much out of the loop to tell for sur

> Point is, there are characteristics of shared lib implementations that
> cannot be abstracted away... so is it worth trying?

Nope, it has to be left up to the user.  Which is what libtool does.

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

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

[Richard Henderson]

On Wed, Feb 27, 2002 at 04:11:35PM +1300, Bryce McKinlay wrote:
> If we did that, what are the chances of hitting this 8k entry limit?

Dunno.  I'd have to check with a build without current binutils.

With current binutils we have available a number of relocs that
avoid the use of .got entries.  With that, for the entire libgcj,
we have

 25 .got          0000bad8  000000000084ca88  000000000084ca88  0083ca88  2**3
                  CONTENTS, ALLOC, LOAD, DATA

So 47k of the 64k available to a single object file is used.
I suspect that without the new binutils optimizations, we'd
be using in the neighborhood of 100k.

I guess depending on how you split up the build, you have a
decent shot at making it under the limit.

> Is there an easy way to get a count of the number of GOT entries
> used in a .o?

objdump -r foo.o | grep LITERAL | cut -f3- -d' ' | sort -u | wc -l


r~

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

[Richard Henderson]

On Tue, Feb 26, 2002 at 08:44:11PM -0500, Jeff Sturm wrote:
> On 25 Feb 2002, Alexandre Oliva wrote:
> > > - real incremental linking (*not* convenience libraries, which are a lousy
> > > substitute).
> > 
> > Which of the definitions of incremental linking are you talking about?
> 
> ld -r

Do not do this.  Alpha has an architectural limit of 8k got entries
per object file.  To-date, no single source file has crossed this
limit, so it hasn't been a problem.

When the objects are left separate until link time, the linker can
arrange for each of them to have their entire 8k quota.

When you start smashing object files together, the resultant object
file still has the 8k per-object limit.  Put enough of them together
and it's relatively easy to make the link fail.


r~

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

[Jeff Sturm]

On 25 Feb 2002, Alexandre Oliva wrote:
> > - real incremental linking (*not* convenience libraries, which are a lousy
> > substitute).
> 
> Which of the definitions of incremental linking are you talking about?

ld -r

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

I'm talking about the dllimport/dllexport mess.  Actually the dllexport is
solved, I think... it's the dllimport that can't be automated by libtool.

Point is, there are characteristics of shared lib implementations that
cannot be abstracted away... so is it worth trying?

The latter is a problem for libgcj on windows.  C/C++ would use
__attribute__((dllimport)) to import data members.  Java has no such
mechanism however.

Jeff

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

[Richard Henderson]

On Mon, Feb 25, 2002 at 12:59:18AM -0300, Alexandre Oliva wrote:
> How many of the problems that were blamed on libtool were really bugs
> in libtool?  How many times we didn't have problems just because we
> were using this package?  Is it really worth to ditch it in favor of
> a more limited solution that will require effort to put in place and
> maintain?

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

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.

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.

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

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.


r~

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

[Richard Henderson]

On Mon, Feb 25, 2002 at 12:45:11AM -0500, Jeff Sturm 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?

No.

The rules for building libgcc_s are quite simple, and are completely
contained within one single makefile rule, which is brought in from
some target-specific makefile fragment.

The problems we're having with libgcc_s are philosophical wrt how it
should be partitioned and used.  There are zero problems with the
actual construction of the library.


r~

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

[Alexandre Oliva]

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

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

[Alexandre Oliva]

On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote:

> On Mon, Feb 25, 2002 at 03:17:02AM -0300, Alexandre Oliva wrote:
>> On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote:
>> 
>> > I agree here; it seems we spend more time undoing libtool's abstraction
>> > than libtool spends adding it.  :-)
>> 
>> Do you really mean this?  I'd like to know of such situations, in
>> which you had to undo libtool's abstraction.  That's pretty sad.

> Mainly I'm referring to the current situation.

Aha!  So, it turns out that the current situation had nothing at all
to do with libtool.  The whole issue was on how to pass -shared-libgcc
to the link command issued by libtool, and the implications of doing
so for other systems.

Ok, I'll give you that libtool made this non-optimal by requiring such
flag to already be present at its configuration time, which is what
confused RTH.  IMO, this may be addressed in future releases of
libtool.  But hey! if this is all you have to count in as `undoing
libtool's abstraction', then it seems that you're pretty satisfied
with it :-)

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

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

[Phil Edwards]

On Mon, Feb 25, 2002 at 03:17:02AM -0300, Alexandre Oliva wrote:
> On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote:
> 
> > I agree here; it seems we spend more time undoing libtool's abstraction
> > than libtool spends adding it.  :-)
> 
> Do you really mean this?  I'd like to know of such situations, in
> which you had to undo libtool's abstraction.  That's pretty sad.

Mainly I'm referring to the current situation.  With regards to libstdc++,
I've been lucky enough to be able to leave libtool discussions to others.


-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[Alexandre Oliva]

On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote:

> I agree here; it seems we spend more time undoing libtool's abstraction
> than libtool spends adding it.  :-)

Do you really mean this?  I'd like to know of such situations, in
which you had to undo libtool's abstraction.  That's pretty sad.

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

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

[Phil Edwards]

On Mon, Feb 25, 2002 at 12:45:11AM -0500, Jeff Sturm wrote:
> On 25 Feb 2002, Alexandre Oliva wrote:
> 
> > 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.
> 
> For any casual, naive attempts to build a shared lib I would
> wholeheartedly recommend libtool.  For specific use like libgcj (and
> probably libstdc++) it is more debateable.

I agree here; it seems we spend more time undoing libtool's abstraction
than libtool spends adding it.  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[Jeff Sturm]

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?

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

For any casual, naive attempts to build a shared lib I would
wholeheartedly recommend libtool.  For specific use like libgcj (and
probably libstdc++) it is more debateable.

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.

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

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

> Is it really worth to ditch
> it in favor of a more limited solution that will require effort to put
> in place and maintain?  I'm not sure.

For libgcj, we could always fall back to static-only on targets where we
don't know how to build shared libs.  I don't have much confidence that
such targets would work even with libtool anyhow.  For instance, libgcj
assumes public data symbols are exported by default, which certainly isn't
true on windows at least.  That sort of detail isn't hidden by libtool's
abstraction.

Jeff

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

[Alexandre Oliva]

On Feb 25, 2002, Bryce McKinlay <bryce@waitaki.otago.ac.nz> wrote:

> Alexandre Oliva wrote:
>>> frankly, the platforms on which libtool is supposed to be magically
>>> helpful are platforms which IMHO need to die, and the sooner we
>>> abandon them the better.
>>> 
>> 
>> Yay!  HP-UX, AIX, Solaris, Windows, no more!

> Are you saying that "gcc -shared" does not currently work on these
> platforms?

Nope.  I'm saying that there's a bit more than gcc -shared.  There are
library naming conventions.  There are versioning mechanisms that vary
from system to system.  There are options to get libraries to find one
another at run time.  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.

The only advantage I see for GCC in keep on using libtool is the
abstraction.  Abstraction comes with a price, though: it becomes
harder to peek into the implementation details.  But do people really
want to do it?  How many of the problems that were blamed on libtool
were really bugs in libtool?  How many times we didn't have problems
just because we were using this package?  Is it really worth to ditch
it in favor of a more limited solution that will require effort to put
in place and maintain?  I'm not sure.

As I wrote before, I don't oppose this move.  But it shouldn't be
taken lightly either.  There may be some (or a lot) to gain, but I'm
pretty sure there's a lot to lose.

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

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

[Bryce McKinlay]

Alexandre Oliva wrote:

>>frankly, the platforms on which libtool is supposed to be magically
>>helpful are platforms which IMHO need to die, and the sooner we
>>abandon them the better.
>>
>
>Yay!  HP-UX, AIX, Solaris, Windows, no more!  
>

Are you saying that "gcc -shared" does not currently work on these 
platforms?

regards

Bryce.

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

[Alexandre Oliva]

On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote:

> frankly, the platforms on which libtool is supposed to be magically
> helpful are platforms which IMHO need to die, and the sooner we
> abandon them the better.

Yay!  HP-UX, AIX, Solaris, Windows, no more!  GNU/Linux for everyone!
:-)

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

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

[Phil Edwards]

On Mon, Feb 25, 2002 at 01:04:58PM +1300, Bryce McKinlay wrote:
> 
> I must admit that, after a frustrating afternoon yesterday trying to 
> figure out silly libjava build problems when I really wanted to do 
> productive gcj hacking, I am sympathetic to RTH's recent suggestion that 
> we get rid of libtool (and automake?) and instead make sure that "gcc 
> -shared" knows how to build a shared library on all the platforms that 
> we care about.

I would fight the removal of automake.  It's been awfully darn handy for
maintaining libstdc++.  (Yes, the currently-required version has its problems
with subdirs, but the current automake release seems to have fixed those.)

Libtool is completely opaque to me.  I wouldn't fight its removal, but
I'm not pushing for it either.  I also never use it in any of my own
projects... [maintainer hat OFF] frankly, the platforms on which libtool
is supposed to be magically helpful are platforms which IMHO need to die,
and the sooner we abandon them the better.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

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

[Brian Jones]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> So, is there anything important that we would lose from such a change?
> Is there anything that libtool can do that GCC will never be able to
> do? What platforms do we care about that GCC currently cant build a
> shared library on (windows perhaps?).

Mingw GCC produces .dll files just fine.

Brian
-- 
Brian Jones <cbj@gnu.org>

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

[Bryce McKinlay]

Nic Ferrier wrote:

>I'm sorry about that. It seems to the fault of my patch.
>
>I did do a full test (configure, build and install) of the patch on a
>fresh check out (with the diff applied). I'm not sure why that didn't
>catch the problem.
>

It is a dependency problem - ie if you touch a source file it will cause 
everything to be rebuilt rather than just the other files which depend 
on what you changed.

I must admit that, after a frustrating afternoon yesterday trying to 
figure out silly libjava build problems when I really wanted to do 
productive gcj hacking, I am sympathetic to RTH's recent suggestion that 
we get rid of libtool (and automake?) and instead make sure that "gcc 
-shared" knows how to build a shared library on all the platforms that 
we care about.

I am convinced that this would result in a much more maintainable, 
transparent, and above all _fast_ build system, in addition to making it 
easier to implement libjava-specific requirements like package-at-a-time 
compilation.

So, is there anything important that we would lose from such a change? 
Is there anything that libtool can do that GCC will never be able to do? 
What platforms do we care about that GCC currently cant build a shared 
library on (windows perhaps?).

regards

Bryce.