Mailing List Archive

At Mon, 19 Jun 2006 14:26:48 +0200,
Simon Josefsson <jas@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,
Marcus

if HAVE_W32_SYSTEM

LTRCCOMPILE = $(LIBTOOL) --mode=compile $(RC) \
`echo $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) | \
sed -e 's/-I/--include-dir /g;s/-D/--define /g'`

%.lo : %.rc
$(LTRCCOMPILE) -i $< -o $@

gpgme_res = versioninfo.lo
gpgme_res_ldflag = -Wl,.libs/versioninfo.o

no_undefined = -no-undefined
export_symbols = -export-symbols $(srcdir)/gpgme.def

install-def-file:
$(INSTALL) $(srcdir)/gpgme.def $(DESTDIR)$(libdir)/gpgme.def

uninstall-def-file:
-rm $(DESTDIR)$(libdir)/gpgme.def

gpgme_deps = $(gpgme_res) gpgme.def
else
gpgme_res =
gpgme_res_ldflag =
no_undefined =
export_symbols =
install-def-file:
uninstall-def-file:

gpgme_deps =
endif

libgpgme_la_LDFLAGS = $(gpgme_res_ldflag) $(no_undefined) $(export_symbols) \
$(libgpgme_version_script_cmd) -version-info \
@LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@
libgpgme_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \
@LTLIBOBJS@ $(srcdir)/libgpgme.vers $(gpgme_deps)
libgpgme_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \
@GPG_ERROR_LIBS@



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

> At Mon, 19 Jun 2006 14:26:48 +0200,
> Simon Josefsson <jas@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.

/Simon

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Wed, 21 Jun 2006 17:33:30 +0200,
Simon Josefsson <jas@extundo.com> wrote:
>
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
>
> > At Mon, 19 Jun 2006 14:26:48 +0200,
> > Simon Josefsson <jas@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 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 used your socklen.m4 from gnulib, nice work. :)

Thanks,
Marcus



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

> At Wed, 21 Jun 2006 17:33:30 +0200,
> Simon Josefsson <jas@extundo.com> wrote:
>>
>> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
>>
>> > At Mon, 19 Jun 2006 14:26:48 +0200,
>> > Simon Josefsson <jas@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. :)

Thanks!

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>

-#if HAVE_SYS_SOCKET_H
-#include <sys/socket.h>
-#else
-#if HAVE_WINSOCK2_H
+#if defined _WIN32 || defined __WIN32__
# include <winsock2.h>
-#endif
-#if HAVE_WS2TCPIP_H
# include <ws2tcpip.h>
+#else
+# include <sys/socket.h>
#endif
-#endif

#include <sys/time.h>


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Tue, 04 Jul 2006 13:43:39 +0200,
Simon Josefsson <jas@extundo.com> wrote:
>
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
>
> > At Wed, 21 Jun 2006 17:33:30 +0200,
> > Simon Josefsson <jas@extundo.com> wrote:
> >>
> >> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
> >>
> >> > At Mon, 19 Jun 2006 14:26:48 +0200,
> >> > Simon Josefsson <jas@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@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@extundo.com>.

Thanks,
Marcus


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

>> > 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.

It seems 1.3-cvs require some more work to build under MinGW, and
since 1.2.2 works fine for me, with the minimal patch, I think I'll
stay with 1.2.2 until someone makes 1.3-cvs work under MinGW.

>> 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.

I'm not exactly sure either, but I don't have any good documentation
to build on. The MSDN documentation regarding which platforms have
which features seems incorrect. For example, it says on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/getaddrinfo_2.asp
that getaddrinfo exists on many platforms (e.g., Win95), but the only
system I've actually found it on is Windows XP.

I think the only sane way to deal with this is to install things that
seem to work now and wait for people to report when it doesn't work.

> The "right" solution to these problems is to generate the header file
> from a header.in file. However, we try to avoid that.

I understand, we do it that way in GnuTLS, but it complicates things,
and I'm not sure it is worth the trouble.

/Simon

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Tue, 4 Jul 2006 15:18, Simon Josefsson said:

> It seems 1.3-cvs require some more work to build under MinGW, and
> since 1.2.2 works fine for me, with the minimal patch, I think I'll
> stay with 1.2.2 until someone makes 1.3-cvs work under MinGW.

Indeed, there are some things fixed in 1.2 which have not been ported
to the trunk.


Salam-Shalom,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel