Re: -no-undefined on Win32

[Peter Rosin]

On 2014-04-29 17:30, Evgeny Grin wrote:
> 29.04.2014, 11:36, "Peter Rosin":
>>>>  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?
>> 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!
> So again we return to first question.
> What's advantage of requiring "-no-undefined" flag on win32?
> If code is designed well for win32 then compiler/linker can create shared 
> lib. No advantage of using "-no-undefined" as lib will not use undefined 
> symbols in any way.
> If code is not designed for win32 then compiler/linker will fail to create 
> shared lib. No advantage of using "-no-undefined".

You are too focused on shared libs, you cannot ignore static libs like that.
You also cannot ignore Cygwin and AIX, which are Posixy enough to make the
"code designed for win32, or not" distinction fall apart. The -no-undefined
option is not specifically tied to win32, it is tied to all systems incapable
of linking shared libraries with undefined symbols.

> For linux systems I see advantages of "-no-undefined": to force produced lib 
> to have all symbols defined (or fail) and to check that all symbols are 
> defined for lightweight emulation of win32 behavior.
> But for win32 "-no-undefined" flag must be used automatically as real checks 
> for undefined symbols will be done by linker anyway.

Here you are making the (perhaps common?) mistake of mixing the ld
flag --no-undefined (two dashes) with the Libtool flag -no-undefined (one
dash).

The ld flag is indeed documented to behave as you say, but the Libtool flag
is not. Libtool -no-undefined will be ignored on most systems and will have
effect only on systems which cannot link shared libraries at all with
undefined symbols (such as win32, Cygwin and AIX). Passing -no-undefined to
Libtool will not make Libtool pass --no-undefined to ld.

>>>>  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'm a volunteer. :)
> I'm not suggesting to delete or change "-no-undefined" flag. All projects 
> that have this flag will continue to function as before.
> But new projects can skip unnecessary step, unless they want to have no 
> undefined symbols on Linux/other platforms - in this case "-no-undefined" can 
> be used as before.

You would break old projects that rely on a consciously left out
-no-undefined flag, i.e. projects that have made the decision that
a static lib is a perfectly fine outcome on some systems. Those
projects would fail with your suggested changes when the shared
library cannot be linked, because of unresolved symbols.

>>>  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?
> Currently you have to properly write code AND specify "-no-undefined" for 
> win32.

Again, -no-undefined is not tied to win32 specifically, it's also
needed on some Posixy systems.

> So current behavior results in working library in less cases as specifying 
> "-no-undefined" without correct code will not result in working library.

Again, a static library is not an automatic fail.

>> Because it breaks projects depending on current behavior?
> I'm not suggesting to remove this option, so projects depending on current 
> behavior will continue to work as before. Only will fail in less cases. :)

Not true, see above.

Cheers,
Peter