Edward J. Sabol wrote:
> Drazen, you've done a excellent job of explaining the problems that libtool
> has on Solaris (and possibly other platforms).
Oh, I haven't even started. :-)
The first thing to do is to ensure correctness. Then optimizations come
into picture.
> implemented. In either case, IMHO, the preferred course of action would be to
> get the bugs in libtool fixed instead of going around telling package
> maintainers that they shouldn't use libtool. Have you contacted the libtool
> maintainers and itemized the bugs you've found and your proposed solutions?
> Or better yet, have you submitted patches?
Sort-of, kind-of. No patches, on purpose. There was some contact and
limitted amount of discussion. Let me explain.
Every time in the past two years (at least) when I mentioned that libtool
ignores LDFLAGS when linking libraries, somebody would say that the CVS
version does that. And then somebody else would mention that the
implementation was a horrible kludge. I've never looked into that code, so
I don't have an opinion on the kludge status, but I would like to point
out that the code was in CVS for at least two years and it has not been
released.
I reported that Apogee C problem about two years ago and then provided a way
to identify that compiler. I suppose it's rather easy to write the check
once you know how to identify the compiler, but the fix was never
released. Which means that libtool is essentially unmaintained. There were
several releases in those two years, but I think they can be categorized
as a desperate fixes in cases when libtool wasn't working on some platform
at all. I'm quite sure that one of them was to have the working version
(up to some point) on Tru64. But no more than that.
> If you have and the libtool
> maintainers are unresponsive to your concerns, then I'll agree you have a
> legitimate beef here.
Provided that there are some maintainers left. I decided to stop wasting
time on libtool when we couldn't agree on whether not passing -R was a bug
(according to me) or a missing feature (according to someone who answered
my bug report). If we can't reach the same conclusion about that, I don't
think we can work together without much frustration on both sides.
I had some other plans concerning portable build infrastructure, but all
that failed miserably. I wasn't trying hard enough, though. (Lack of
developers on platforms I didn't have access to, in case you're wondering.)
I think I deleted the part where you said it would be more productive
to do something about the whole thing instead of telling developers not
to use libtool. (Or something to that effect, sorry if it's not a good
enough quote). You're right, of course. But I'm not telling the developers
that they should not use libtool. I'm only telling them that they
shouldn't promote libtool as an infrastructure which solves linking
problems, because it doesn't. That inevitably leads to pointing out some
of libtool's failures, from which one might draw the conclusion that I'm
advocating banishing libtool, but I don't think I wrote that. I think it
should rest in peace.
> Personally, I think using libtool is a big win for
> package maintainers, who shouldn't have to keep re-inventing the same wheel
> over and over again.
Without a doubt. If you tell me that you don't know how to build libraries
on 10 platforms and that the result of using libtool would be better than
the result of your home-made kludge, that's fine. That's understandable.
I don't have a build infrastructure solution to recommend. There are some
build systems out there which might work better for wget (since it has a
modest requirements), but I'm not sure if they would be better for other
sources as well. So if you don't know of a better solution, go ahead and
use libtool. But keep in mind that it's not a catch-all solution and don't
promote it as such.
The one good thing about the breakage introduced by libtool (and related
utilities) is that the breakage in all tarballs which use them is more or
less the same. So after some time (and a lot of frustration, if you
thought that libtool just works, because there is so many libtool
advocates) you learn how to bypass the breakage. It's not pretty and it
takes too much time, but it can be done. If everyone had their own build
solution which doesn't work, linking correctly would take much more time.
So use libtool if you don't have anything better. That would make my life
easier too, if I want to install your software. (This is ironic, but it's
true.)
> That assumes any libtool deficiencies you've cited can be fixed, of course.
This is a debatable point. Most of the problems I cited can be fixed,
because they were centered about correctness. But there is an optimization
issue. Not relevant in case of wget, because it's a small utility. But
it's very relevant for Gnome or KDE utilities, because they usually link
with more than 20 libraries. And they are usually deployed on ELF systems
and ELF performance sucks. And then there is Unix 98 spec, which requires
some things, so linkers which have certain performance features don't have
them turned on by default (but this might be backwards compatibility
issue, I'm not sure).
People who implemented libtool weren't exactly idiots. If you look at the
documentation, you'll find some design decisions which go against the
platform recommendations (maybe even rules). From my point of view today,
it's a suicidal design decision. But maybe it made perfect sense at the
time. All build tools take some control away and offer something else in
return. The question is only if the trade-off is good for the particular
application. Libtool was designed to make binaries and libraries which
work, but it sacrifices optimization and ease of maintainance (eg. what
happens to your Gnome installation if you want to use Berkeley DB 3.x
instead of 1.x or 2.x). There are some bugs, but that can be fixed.
Essentially it tries to work with the least common denominator of all
systems. That approach doesn't scale, so KDE implemented an interesting
work-around to launch programs. Some people would call it a neat hack and
some would call it a horrible kludge. It doesn't matter. I don't know much
about C++, so I can't make any claims here, but if it was C source, I
would claim that on a number of architectures (at least AIX, IRIX, Solaris
and Mac OS X) one could achieve the similar start-up speed gain by using
the linker features. Provided that one doesn't use libtool, because it
prevents it. And that the ones which don't have those features today would
gain them tommorow, so you'd better have a build system which can use
those features.
The point is that the requirements have changed. Libtool design decisions
might have been OK at the time libtool was concieved, but the times have
changed and they are not good enough any more. So I don't see a point in
beating the dead horse and working on libtool fixes and kludges, although
it might be possible. Gnome's pkg-config thing is a step in the right
direction and it might be a solution on top of libtool (yes, yet another
layer) provided that the fixes in CVS are finally released. I'm not
absolutely sure about this, because I haven't had the time to look into
it, although I promissed.
I regard libtool as a failed experiment, somewhere in the same class with
Swing. Although Swing applications work on Unix, I'd try to use an
alternative if I have any choice, because I don't find trade-offs imposed by
Swing satisfactory. YMMV and all that.
I hope that http://www.software-carpentry.com would provide a solution
that would last for several years. Honestly. :-)
As far as wget is concerned, it wouldn't be a big problem to handle
whatever the final decision brings. I would personally prefer a configure
script which just checks for the library and header locations. It could
use run-path flag as a default, provided that there is a way to stop it
from doing that (since there's no way it can tell wheteher I want
-R/usr/local/lib or -R$ORIGIN/../lib, for example). If it doesn't work on
some platform, people will send patches. Another reason not to use
complicated build tools unless really necessary is that you limit the user
base which can send patches.
Hmm, this turned out to be pretty long. Does that qualify me for the next
XEmacs release coordinator?
--
.-. .-. Sarcasm is just one more service we offer.
(_ \ / _)
| [EMAIL PROTECTED]
|
