Drazen Kacar <[EMAIL PROTECTED]> writes:
> Mostly. There are very few source packages which use libtool, although
> they don't try to build any library, so I wasn't very concerned with
> those. Libtool will probably still do one or two things wrong (or against
> user's wishes), but that's easy to fix. If you're a shared library expert
> and don't mind editing sh scripts.
No need to edit sh scripts. Just substitute your own definitions of the
make variables as in `make LDFLAGS=<my_custom_flags>'.
> > If so, I'm not too concerned, since Wget doesn't build any libraries.
>
> I'm concerned about something else. You're promoting libtool usage. I can
> prove that it doesn't work correctly on some platforms which it allegedly
> supports (according to libtool documentation). If many people say many
> times that libtool solves linking problems, that won't become true just
> because they are saying it so often. But the observable effect is that
> many other developers will never look into linking issues, just because they
> think that there is this magic tool which can do it for them.
No tool is magic. Some work better than others and some have more bugs than
others, but libtool is the best solution I know of for getting a
cross-platform package to link to 3rd-party shared libraries without manual
user intervention. If you know of a better package, I'd be only too happy
to look at it instead.
> > Are you saying it throws away any options you give it (which happened to
> > come from the Makefile's LDFLAGS variable)? Sounds unlikely...
>
> Yes. Try "LDFLAGS=-R/blah ./configure" with a source that uses libtool to
> build some library and watch if -R is still there when it's linking the
> library. It will be preserved when linking binaries, though.
Again, I think you may be conflating Makefile issues with libtool issues.
Do the flags make it down to the libtool call but then they're stripped out
in the libtool-mangled version of the commandline, or do they simply not
make it down to the libtool call in the first place?
> Watch it when it builds the library. It directly invokes /usr/ccs/bin/ld.
> That's a bug.
Have you reported this to the libtool maintainers? What was their response?
> As far as positional linker flags are concerned, it's pretty simple. I
> would like to build wget in this way:
>
> cc -o wget *.o ... -z lazyload -lssl -lcrypto -z nolazyload -lnsl -lsocket ...
>
> The effect is that SSL libraries will be loaded in run-time only when wget
> actually tries to use them (presumably when trying to access https URLs),
> but not otherwise. The start-up is faster and you don't have to have SSL
> libraries if you don't intend to use them, although the binary was linked
> against them. It's probably not very important in case of wget, but we can
> discuss GNOME, KDE and CDE binaries if you want.
I'm sorry, but you're again pretty aggressively in shared library expert
territory here. I'm sure 99% of users don't play around with nolazyload,
and most probably don't even know it exists. If you want to do this stuff,
go to it! You can override whatever Makefile variables you need to get your
special behavior. If you need to get libtool out of the picture completely
for some reason, go for it! Simply do:
% make LINK='$(CC) $(CFLAGS) $(LDFLAGS) -o $@'
Or whatever defintion you care to use.
> > > When compiling libraries it severely limits the
> > > choice of compilers (might be platform dependant, but I doubt it).
> >
> > Really?? I thought the general design was that if it didn't know something
> > about a particular OS or compiler, it'd just pass through what you gave it
> > unchanged.
>
> But it must know. A few years back I was trying to play with Apogee C
> compiler on Solaris. That compiler uses -PIC to generate position
> independent code.
Ah. I didn't catch your "When compiling libraries" -- I have to remember
most of your beef with libtool is not germane to the discussion of its use
to link to shared libraries.
> If there was a --with-pic-flag, then I would be able to use small PIC
> model if I choose to (and in the end I might suffer link error if the code
> is too big, but that would be because of my decision). But what's more
> important is that I would be able to specify --with-pic-flag=PIC and I
> would be able to compile the source with Apogee C compiler, without having
> to edit the configure script manually (and I'm sure you know how much fun
> that is).
Have you suggested such a feature to the libtool maintainers? They may be
totally open to that, especially if you send them a patch rather than
demanding they implement it.
> > Why would you want to tell it to discard all flags it thinks are correct?
>
> Because I don't think they are correct. And I don't think they are
> desirable. So I want to put my own instead, without resorting to editing
> configure script, libtool script, *.la files, huge amount of cut & paste
> operations (just to insert some linker flags) etc.
Just do Makefile variable substitutions so that libtool isn't even in the
picture.
> I am human and libtool is program. The difference is that humans are able
> to read the documentation and do something smart, sometimes.
The authors of libtool are also "able to read the documentation and do
something smart, sometimes".
> > > > Nothing?? Sorry, but that's pretty massive hyperbole.
> > >
> > > Well, I don't remember ever seeing libtool linking libraries in a way I
> > > wanted them to be linked. No matter what I put in LDFLAGS or LIBS. Which
> > > is why I end up linking libraries by hand in spite of libtool. That's not
> > > a massive hyperbole, that's a massive amount of work required to have
> > > libraries linked in a way which platform documentation recommends.
> >
> > Have you had these problems when libtool is only used for linking to
> > existing libraries? If not, again, I don't see how this affects the
> > decision to use libtool with Wget.
>
> It doesn't. It's a response to your statement that my statement was a
> pretty massive hyperbole.
You didn't qualify your statement to say that it didn't apply to the usage
of libtool that we're discussing here. As stated, it's massive hyperbole.
Even qualified it'd be massive hyperbole. It's ridiculous to say that
libtool gives you _0_ benefit just because it makes the wrong decision in
certain circumstances.
> > > Yes, but it shouldn't produce unusable binary when compiling with gcc.
> > > If I didn't say --with-ssl=/usr/local than it's OK if I don't get SSL
> > > support, but it's not OK if I end up with unusable binary without any
> > > error or warning.
> >
> > You don't. You get a binary that simply doesn't have SSL support, and you
> > get a big fat warning about it.
>
> No, I got a big fat warning with the second try, by using another
> compiler. Building with gcc produced unusable binary because gcc adds
> -L/usr/local/lib behind your back, but not -R/usr/local/lib. Last time I
> was checking IRIX documentation, the native compiler there was doing the
> same thing.
Yuck. Ideally compilers should not automatically add any -L parameters
unless they add the corresponding -R parameter (or its equivalent on the
particular OS). Anyway, see my response to Hrvoje's post as to how I feel
we should deal with this.
> It would be nice to have some tool which knows a thing or two about
> platforms (dynamic loader, to be more precise) and compilers, so it could
> do the right thing for you. Libtool knows on which platform it's running
> and it knows which compiler is being used, so libtool could do that. But
> the fact is that it doesn't. So you'd have to do it yourself. All this
> started when you said you wanted to use libtool because you don't want to
> check each possible platform/compiler combination. But you will.
Huh? So you're saying libtool completely fails to work as a cross-platform
aid to linking to 3rd-party shared libraries? Again, you're way into
hyperboleville here.
> That $ORIGIN thing is Solaris specific. In run-time it evaluates to the
> directory where the binary lives (the information is provided by the
> kernel, so it's always correct). So if wget lives in /usr/local/bin,
> run-time linker will try to search for libraries in /usr/local/lib. That's
> a nice feature which allows you to build binary packages which don't
> depend on hardcoded run paths.
Yes, I'm familiar with Solaris' $ORIGIN thing. The way you're using it is
also completely inappropriate if the OpenSSL libraries are not in
/usr/local/lib, so don't have any illusions that you're being an everyman in
the way you're linking here.
> LD_OPTIONS controls ld directly, so I thought that I'd win with this, that
> I found a way to bypass libtool. But little did I know about the evil ways of
> the thing which wants to be linker instead of linker.
So substitute your own linker with the LINK make variable, like I've said.
> Besides, the above is the documented and recommended build procedure on
> Solaris, so it is the *standard* way to build on that platform.
Hm? Using $ORIGIN/../lib is the "*standard*" way to build on Solaris? Can
you show me the document that states that?
> But I want the appropriate -L to be put there by the configure script.
> I don't think this is unreasonable request, because -L and -l flags are
> specified by POSIX.2 (c89 utility), while -R is not. What I want is a build
> process which uses only documented POSIX.2 interfaces. I can take care
> about the rest.
Most users want it to just work, rather than wanting arbitrary standards
compliance.
> It doesn't have to be the default. Having to pass
> --posix-me-harder or --libtool-is-a-fool flag is perfectly acceptable.
Presumably `make LINK=...' is also acceptable.
> There are only platform specific
> ways to build, which should be documented for every platform. And build
> tools (such as autoconf/automake/libtool trinity) should conform to that,
> because there is not a solid piece of ground anywhere else.
No argument here.
---------------------------------------------------------------
Dan Harkless | To help prevent SPAM contamination,
GNU Wget co-maintainer | please do not mention this email
http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
