Link with -no-undefined

Simon Josefsson jas at
Tue Jul 4 13:43:39 CEST 2006

Marcus Brinkmann <marcus.brinkmann at> writes:

> At Wed, 21 Jun 2006 17:33:30 +0200,
> Simon Josefsson <jas at> wrote:
>> Marcus Brinkmann <marcus.brinkmann at> writes:
>> > At Mon, 19 Jun 2006 14:26:48 +0200,
>> > Simon Josefsson <jas at> wrote:
>> >> 
>> >> Adding -no-undefined flag to libtool has a side-effect of producing an
>> >> DLL of libgcrypt when cross-compiling to mingw32.
>> >>
>> >> The Libtool documentation for the flag is somewhat confusing, but the
>> >> intention is that the flag is used when the library doesn't need any
>> >> externals symbols, which is true for libgcrypt.
>> >
>> > In GPGME, we have something like the below.  We also have a resource
>> > file and a symbol export definition file (eg
>> > libgcrypt/w32-dll/libgcrypt.def).  I think that any port of libgcrypt
>> > to the mingw32 target should have all of these, and whatever else is
>> > required to make libgcrypt work on w32 targets...
>> Thanks.  My point was that with -no-undefined, I do get a DLL that
>> seems to work fine on w32 machines.  So I think my patch could be
>> applied without your additional work.  If someone wants to integrate
>> your additional stuff, that would be fine too, of course.
> Frankly, I do not understand how you get a DLL at all.  It doesn't
> even compile for me, there is at least a msghdr issue, and there was a
> socklen_t issue until I fixed this right now.

I'm using libgcrypt 1.2.2, which seem to work fine under Windows when
build with LDFLAGS=-no-undefined.

> I committed the changes to bring the windows port framework in line
> with what is in GPGME, but the port remains incomplete.  If you have
> any patches to fix the remaining issues, why not send them in?

I tried building 1.3-cvs now, and I got the same problem you did.  The
problems seem to be due to src/ath.h.  How about reverting it to
what's in 1.2.2, which seems to work?  Maybe other things are fixed in
1.2.2 that is broken in 1.3-cvs too.

> I used your socklen.m4 from gnulib, nice work. :)


However, is it a good idea to use #ifdef HAVE_SYS_TYPES_H checks in an
installed header file?  Not all programs include a config.h that have
those define.  How about this?

Index: gcrypt.h
--- gcrypt.h	(revision 1160)
+++ gcrypt.h	(working copy)
@@ -29,16 +29,12 @@
 #include <sys/types.h>
-#include <sys/socket.h>
+#if defined _WIN32 || defined __WIN32__
 # include <winsock2.h>
 # include <ws2tcpip.h>
+# include <sys/socket.h>
 #include <sys/time.h>

More information about the Gcrypt-devel mailing list