Link with -no-undefined

[Marcus Brinkmann]

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. :)
> 
> Thanks!
> 
> 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>.

Thanks,
Marcus