Dan Harkless wrote:
> 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.
No need. Just use libtool.
> > 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?
Libtool throws them away. A design decision.
> > 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?
I don't remember. I think I mentioned it once or twice on mailing lists in
front of people who work (or have worked) on libtool.
> What was their response?
Nothing.
> 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.
And I'm sure that a large number of Gnome users complain that application
start-up time is too big. I'm also sure that 99% of NT users don't know
anything about lazy loading, but they get it by default, so they don't
have to.
> 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.
That might work, but I don't see why libtool is being used in the first
place if I need to remove it entirely. Because most users don't care?
> Have you suggested such a feature to the libtool maintainers? They may be
I think not. Because I don't think there's any point in spending time on
libtool.
> totally open to that, especially if you send them a patch rather than
> demanding they implement it.
The only thing I demand from the utilities is to implement what they
document to be implemented. Removing something from the documentation is
also fine, unless I'm paying for the software in question.
> > 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".
Hopefully.
> > 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.
You didn't qualify the term "you." If it applies to me personally, then
it's pretty much accurate. The last time I let libtool do linking on its
own was when I didn't know what it would produce.
> 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.
There's a small problem with that. If there are no archives installed on a
system (but only shared objects), your solution will not produce the best
results.
> > 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.
Maybe. I think you'd end up with the same amount of work with or without
libtool if you want to be foolproof. The added benefit of using libtool
would be zero if that's the case. But I can't prove it unless you try it,
so go ahead.
> 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,
Which is exactly the reason why they are in /usr/local/lib.
> so don't have any illusions that you're being an everyman in the way
> you're linking here.
Yeah, but I fail to see the point.
> > 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?
It's standard if you want to produce binary packages which can be
installed at any prefix. Nothing else comes to my mind.
> > 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.
More power to them.
> > 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.
I'll have to try with 10 or 20 tarballs, before reaching a decision.
--
.-. .-. Sarcasm is just one more service we offer.
(_ \ / _)
| [EMAIL PROTECTED]
|
