Dan Harkless wrote:
> Drazen Kacar <[EMAIL PROTECTED]> writes:
> > > What was their response?
> >
> > Nothing.
>
> Perhaps you'd get one if you made a more official bug report.
Perhaps. But one of the best ways to piss off users is to claim "not a bug"
for something that is a pretty obvious bug, or, even worse, a design flaw.
That's the point where I draw the line. I don't see why I would want to
get another response like that. There is a chance that it would be
recognized as a bug, but the whole thing looks like an arbitrary decision of
clergy based on the phase of the moon or whatever and I really don't want
to waste time on that.
> > 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?
>
> No, because it does the right thing for most users.
I don't know what you consider to be the right thing. Most users are not
able to tell if the resulting executables and libraries are in accordance
with the platform specifications. Therefore most users can only say if it
works for them or not. But that statement implies "at this point in time,"
which is rarely explicitely qualified, so you might have missed that point.
And most users are not able to tell whether the binaries they have now
would work in a year or if they would have problems with upgrading to the
new version or whatever.
I don't understand why you keep bringing "most users" in discussion. You
could have used "most platforms" or "most compilers" or "the most common
combinations" or anything else which doesn't require conducting poll.
Why the fixation on "most users" who "don't care about the standards?" Or
was it "arbitrary standards?"
> > > > 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.
>
> Your original statement was a general one, not just applying to you
> personally.
Yes, it was. I'm doing what I'm doing in spite of libtool because I want
to have a system which doesn't suck. "Doesn't suck" means that I want
executables and libraries to be built correctly (as the platform
documentation recommends) and somewhat optimized. I want to have it that
way, because I want my utilities and libraries to:
a) work always
b) upgrade easily and in a predictable way
Libtool does not produce libraries which conform to (this) platform's
recommendations. Therefore I cannot trust it to produce something which
won't cause me problems in the future. The platform in question uses ELF
objects, so the possible fixes in the already existing objects are very
limited (unlike AIX, where you can change the run-path in the existing
executable, for example).
Libtool does what it does by design, not because of some bugs. I listed
some existing bugs as well, because they can illustrate design decisions.
Which are pretty simple: you shall let libtool manage all your libraries
and libtool shall do it in accordance with its own rules and not
necessarily according to the platform rules.
I can understand why this approach was taken in libtool's design, but the
results are simply not satisfactory and one can have various difficulties
with the libraries at arbitrary points in the future. Because of design.
That's why libtool is not trustworthy. What follows is that libtool should
be avoided if possible. I don't think this is a ridiculous position and
I'm not sure why you're qualifying it as such. Perhaps I stumbled upon
some taboo?
What follows next is pretty simple: if some tool should be avoided, it
gives you zero benefit.
> > 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.
>
> Care to elaborate on that (if you haven't already done so in a later
> mail)?
If I understand your idea correctly, you want to link with the archive
version (libcrypto.a) at configure time. If the archive version does not
exist anywhere on the system and only the shared library exists, your
configure check will fail and you won't end up using SSL, although it's
available.
> > 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.
>
> Who said anything about being foolproof?? No software is completely
> foolproof, my friend. I just want it to work in the common cases.
Fine by me.
> > > 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.
>
> That's great, but not everyone is willing or able to put all 3rd-party
> shared libraries in the same directory.
I found no obstacles for SSL libraries, so I put them where I put them,
because it was the most convenient place. I don't have Oracle libraries in
/usr/local/lib and I'm using some other arrangements for the utilities
which need to be linked with them.
> > > > 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.
>
> Okay, now you're qualifying the statement. So apparently Sun does _not_
> say that that's the "one true way" to link to shared libraries, as you
> originally stated.
I don't remember using "one true way" construct and I can't think of a
situation where I would apply it.
Anyway, you don't have to use $ORIGIN if you want to produce relocatable
binary package. You can ship object files and link them during the
installation procedure. That could produce equally good results, but it
usually requires more work.
I would assume that it's obvious that the binary package which can be
installed anywhere on the system is better than the package which can be
installed only at a predefined position. Because it has one feature more,
while everything else is the same.
--
.-. .-. Sarcasm is just one more service we offer.
(_ \ / _)
| [EMAIL PROTECTED]
|
