Quantcast

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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michael Haubenwallner
* configure.ac: Set AM_CONDITIONAL(HAVE_UNDEFINED_SYMS) for mingw32 and
cygwin systems.
* src/Makefile.am: Use -no-undefined libtool flag when we do not
HAVE_UNDEFINED_SYMS, instead of when we HAVE_W32_SYSTEM only.

Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
so libtool needs the -no-undefined flag.
---
 configure.ac    | 8 ++++++++
 src/Makefile.am | 8 ++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index a44f0c8..17a6392 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,17 +85,24 @@ AC_GNU_SOURCE
 have_w32_system=no
 have_w64_system=no
 have_w32ce_system=no
+have_undefined_syms=yes
 case "${host}" in
     x86_64-*mingw32*)
         have_w32_system=yes
         have_w64_system=yes
+        have_undefined_syms=no
         ;;
     *-mingw32ce*)
         have_w32_system=yes
         have_w32ce_system=yes
+        have_undefined_syms=no
         ;;
     *-mingw32*)
         have_w32_system=yes
+        have_undefined_syms=no
+        ;;
+    *-cygwin*)
+        have_undefined_syms=no
         ;;
     *)
        ;;
@@ -495,6 +502,7 @@ fi
 AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes)
 AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes)
 AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes)
+AM_CONDITIONAL(HAVE_UNDEFINED_SYMS, test "$have_undefined_syms" = yes)
 AM_CONDITIONAL(CROSS_COMPILING, test x$cross_compiling = xyes)
 AM_CONDITIONAL(FORCE_USE_SYSCFG, test x$force_use_syscfg = xyes)
 
diff --git a/src/Makefile.am b/src/Makefile.am
index 398ec5e..63710de 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -120,7 +120,6 @@ SUFFIXES = .rc .lo
  $(LTRCCOMPILE) -i "$<" -o "$@"
 
 gpg_error_res = versioninfo.lo
-no_undefined = -no-undefined
 export_symbols = -export-symbols gpg-error.def
 # i686-w64-mingw32.gcc version 4.9.1 takes the long long helper
 # functions from libgcc_s_sjlj-1.dll and not from a static libgcc.  As
@@ -149,7 +148,6 @@ else
 #
 arch_sources = posix-lock.c posix-lock-obj.h posix-thread.c
 gpg_error_res =
-no_undefined =
 export_symbols =
 extra_ltoptions =
 
@@ -163,6 +161,12 @@ endif
 # }}} End Unix part
 #
 
+if HAVE_UNDEFINED_SYMS
+no_undefined =
+else
+no_undefined = -no-undefined
+endif
+
 if HAVE_LD_VERSION_SCRIPT
   libgpg_error_vers_opt = -Wl,--version-script=$(srcdir)/gpg-error.vers
 else
--
2.10.2


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Werner Koch
On Mon,  6 Mar 2017 18:04, [hidden email] 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.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michael Haubenwallner

On 03/07/2017 08:27 PM, Werner Koch wrote:
> On Mon,  6 Mar 2017 18:04, [hidden email] 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/

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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, [hidden email] 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

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Loading...