Re: -no-undefined on Win32

[Peter Rosin]

On 2014-04-29 07:25, Evgeny Grin wrote:
> 29.04.2014, 05:59, "Bob Friesenhahn":
>> On Mon, 28 Apr 2014, Evgeny Grin wrote:
>>>  Good. But requiring "-no-undefined" for Win32 flag lower probability of 
>>> successful compile.
>> In what way does it lower the probability of a successful compile?
>> Static linkage is much more portable than dynamic.
> That was another asked question: why libtool didn't fail if requested dynamic 
> lib was not build.
> Anyway, if I'm building dynamic lib and it was not built, that's called 
> "unsuccessful build".

Here you have a point, methinks. If you have specified -disable-static, it
is surprising that static can be the only output, instead of a fail.

>> The situation you outlined is due to a defective package
>> preparation/build environment.  A proper build has just one version of
>> a given library in a link.
> Could you explain this a little bit?
> In the topic "-no-undefined on Win32" I was talking about only one version of 
> lib.

It is defective since the project has failed to specify -no-undefined when
it proceeds with a link without undefined symbols. Just add the dang flag
and be done with. Yes, I did read the argument that some projects decide to
special-case adding -no-undefined only for systems that must have it to produce
shared libs, or refuses to add it outright, but that's just plain silly. If
someone doesn't want to support weird systems/tools, why not use $CC -shared
directly and erase Libtool from the project instead? Seriously!

>> Regardless, it is very unlikely that libtool will react to your plea
>> (if it does at all) in a timely fashion and so you are best advised to
>> fix your build without relying on significant changes in libtool.
> All my builds were "fixed" already.
> I'd like to improve libtool.
> If *uncommenting* one line and deleting other line in libtool are significant 
> changes, then I'd like to significantly change libtool. :)

You have "forgotten" the needed testsuite changes involved which should verify
the new behavior. Those would probably be more significant than a couple of
one-liners. You're also ignoring the impact on projects relying on the current
behavior, how do you propose to handle them? A new flag? Named what? -undefined?
-no-no-undefined? -has-undefined? -undefined-symbols?

I suppose -disable-shared would do it, but that would *require* projects (or
users) to special-case systems that now only require -no-undefined (which does
nothing on "normal" systems), and that cannot be an improvement.

> Could you answer my main question: why libtool don't follow logic of other 
> GNU tools? Instead of acting as a "tool" and passing required flags to 
> compiler/linker, libtool is acting as mentor and does not do it work until 
> you signal that you aware of something?

Because the current behavior results in a working library in more cases?
Because it breaks projects depending on current behavior?

Or are you mainly referring to your desire to link static libs into a
shared lib? In that case, perhaps because such usage is error-prone on
most systems, and that the check is in place for all systems in the name
of not complicating the Libtool code even further with even more special-
casing for a seemingly questionable scenario?

Cheers,
Peter