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
