Link with -no-undefined
marcus.brinkmann at ruhr-uni-bochum.de
Tue Jul 4 14:34:30 CEST 2006
At Tue, 04 Jul 2006 13:43:39 +0200,
Simon Josefsson <jas at extundo.com> wrote:
> 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 see. Werner ported libgcrypt 1.2.2 in the LIBGCRYPT-1-2-BRANCH. I
just merged those changes into the trunk. This gets us closer, but
still not fully there yet.
> > 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.
Well, 1.3 has some more development, like in the entropy module. I
have to leave it here for now, as this is not what I am currently
working on. If you get further, let us know, and I may get a chance
to look at any patches that are sent to the mailing list.
> > 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?
No, it's a dumb idea. I am embarrassed!
> Not all programs include a config.h that have
> those define. How about this?
I put it in. I don't know what header files on w32 platforms are
reliable, I trust your judgement in that matter.
The "right" solution to these problems is to generate the header file
from a header.in file. However, we try to avoid that.
2006-07-04 Marcus Brinkmann <marcus at g10code.de>
* gcrypt.h: Revert last change, and instead:
[_WIN32 || __WIN32__]: Do not include <sys/socket.h>, but
<winsock2.h> and <ws2tcpip.h>.
Suggested by Simon Josefsson <jas at extundo.com>.
More information about the Gcrypt-devel