ping: [PATCH] Cygwin needs -no-undefined libtool flag.

[Michael Haubenwallner]

Any further thoughts?
Thanks!
/haubi/

On 03/08/2017 01:02 PM, Michael Haubenwallner wrote:
> 
> On 03/07/2017 08:27 PM, Werner Koch wrote:
>> On Mon,  6 Mar 2017 18:04, michael.haubenwallner at ssi-schaefer.com said:
>>
>>> Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
>>> so libtool needs the -no-undefined flag.
>>
>> This needs to be patched in libtool and not in libgpg-error et al.  it
>> might be that upstream libtool already has that.  However due to
>> problems we had with the upstream version we keep our version which has
>> a few patches we require.
> 
> Well, there's nothing libtool can do about here.  Instead, there's a
> (widespread) misinterpretation about the -no-undefined libtool flag.
> 
> Agreed this might be easier to understand when it were not a "no-"flag,
> but this is for historical reasons when there were static libraries only.
> 
> 
> Please let me try to explain:
> 
> Creating a static library does not need to know which libraries to link
> against, as no linking is done at all.  So libtool does not require
> library maintainers to specify enough libraries to resolve all symbols.
> 
> But with the introduction of shared libraries this requirement changed:
> While each operating system does "support" undefined symbols with static
> libraries, some operating systems also do support undefined symbols with
> shared libraries, but some don't.
> 
> On the other hand, each operating system supporting shared libraries
> obviously does support shared libraries without undefined symbols.
> 
> Without the -no-undefined flag, libtool assumes the library does have
> undefined symbols, and does not create the shared library when the
> operating system is known to lack support for undefined symbols in
> shared libraries.
> 
> With the -no-undefined flag, libtool knows that the library maintainer
> does provide necessary libraries to resolve all symbols, so libtool can
> create the shared library even on operating systems without support for
> undefined symbols in shared libraries.
> 
> 
> As far as I can see, libgpg-error does not rely on undefined symbols at all.
> 
> So -no-undefined really makes sense for any platform here, as proposed in
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032186.html
> 
> Beyond that: With linkers that support yelling on undefined symbols (like
> GNU ld with -zdefs flag), the -no-undefined flag allows to unhide obscure
> bugs related to undefined symbols at library linking time already.
> 
> However, because of the -zdefs (or similar) linker flag (where supported),
> I can understand not to add the -no-undefined flag in minor releases,
> to not unhide bugs that do not (seem to) harm when left hidden.
> 
> Uhm, lots of inversive logic here...
> 
> Thanks!
> /haubi/
> 


-- 
Michael Haubenwallner     Senior Software Engineer
SSI SCHÄFER                      IT Solutions GmbH
Friesachstraße 15  8114 Friesach bei Graz  Austria
Phone +43 3127 200-308         Fax +43 3127 200-22