Link with -no-undefined
jas at extundo.com
Tue Jul 4 13:43:39 CEST 2006
Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> writes:
> At Wed, 21 Jun 2006 17:33:30 +0200,
> Simon Josefsson <jas at extundo.com> wrote:
>> Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> writes:
>> > At Mon, 19 Jun 2006 14:26:48 +0200,
>> > Simon Josefsson <jas at extundo.com> 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?
--- gcrypt.h (revision 1160)
+++ gcrypt.h (working copy)
@@ -29,16 +29,12 @@
+#if defined _WIN32 || defined __WIN32__
# include <winsock2.h>
# include <ws2tcpip.h>
+# include <sys/socket.h>
More information about the Gcrypt-devel