Drazen Kacar <[EMAIL PROTECTED]> writes:
> Dan Harkless wrote:
> > Drazen Kacar <[EMAIL PROTECTED]> writes:
> > > I think developers tend to use libtool because they would very much
> > > like to believe that it solves linking problems.
> >
> > And they believe that because in almost all cases, it's true.
>
> On a number of platforms libtool doesn't link the libraries in the way
> that platform documentation recommends.
What platforms? What does libtool do wrong? When you say "link the
libraries", I assume you're talking about building libraries, not linking to
them? If so, I'm not too concerned, since Wget doesn't build any libraries.
> > > In my experience it just takes control from the user
> >
> > What control does it take away?
>
> When linking libraries it ignores LDFLAGS.
Eh? It doesn't know anything about LDFLAGS -- that's a Makefile concept.
Are you saying it throws away any options you give it (which happened to
come from the Makefile's LDFLAGS variable)? Sounds unlikely...
> On SYSV-ish platforms, it picks
> the wrong linker by default (this might depend on the compiler you're
> using, but since the correct linker is actually the compiler you're using,
> I can't find the excuse for this). It takes away the ability to specify
> positional linker flags.
Not sure what you mean by that.
> 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.
> There
> is no sane way to tell it to discard all flags it thinks are correct
> (except those which are specified by POSIX.2, as those are the only ones
> which are always correct).
Why would you want to tell it to discard all flags it thinks are correct?
> > > and offers nothing in return.
> >
> > 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.
Are you sure all these problems you've seen are libtool's fault, and not the
fault of the package authors? The only problems I've ever had with libtool
have been because the package authors weren't using it correctly.
> > > The whole screw-up happens because SSL libraries are in /usr/local/lib.
> > > Pretty standard place, don't you think?
>
> > Yup. It's not the default for OpenSSL, though. It installs in
> > /usr/local/ssl/lib by default. As `configure --help' tells you:
>
> 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.
> > > [7] RPATH $ORIGIN/../lib
> >
> > Sure, just use whatever custom LDFLAGS you would have used without libtool
> > in the picture. It will respect and use them.
>
> I don't know how to use LDFLAGS for this, so I'm using something else
> which bypasses libtool entirely.
Huh? There was no concept of bypassing libtool before it was in the
picture. Not sure what you mean when you say you aren't using LDFLAGS.
How exactly *are* you building?? Can't address your problem if you can't be
more descriptive of your build process.
> But, if libtool decides it should use
> -R/usr/local/lib (or whatever), how do I tell it that it's not a good idea?
It doesn't decide that. configure adds -R<OpenSSL_lib_dir> to LDFLAGS, and
libtool translates that to the appropriate flag for this OS (whether that's
-R<dir>, "-Wl,-rpath -Wl,<dir>", "-Wl,-blibpath -Wl,<dir>", or whatever).
If you don't want that -R parameter to even be fed to libtool in the first
place, simply override the setting for LDFLAGS. Heck, set it to "" if
you're linking some weird way that doesn't use LDFLAGS...
> > It's just that the average user no longer needs to be a shared library
> > expert, as you apparently are.
>
> I'm not.
Well, most non-experts generally wouldn't complain that libtool is taking
away their control (you can't control what you don't understand), and that
they want to link to shared libraries in special, non-standard ways.
> And I don't think one gets "shared library expert" title if one
> just reads a little bit of documentation.
Yeah, it's more a distinction of "people who know very little about shared
libraries" vs. "people who know several things about shared libraries" than
"people who know several things" vs. "people who know almost everything".
---------------------------------------------------------------
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.
