Re: -no-undefined on Win32

[Evgeny Grin]

29.04.2014, 11:36, "Peter Rosin" <address@hidden>:
> 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.
Correct. But this is another topic, which I raised already in this mailing list.

>>>  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".

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.


>>>  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.

>>  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. 
So current behavior results in working library in less cases as specifying 
"-no-undefined" without correct code will not result in working library.

> 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. :)

> Or are you mainly referring to your desire to link static libs into a
> shared lib? 
No, it was another topic that was already discussed.

Thanks for constructive answers!

-- 
Best Wishes,
Evgeny Grin