From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: cross building 1.9.14 for mingw
Date: Sat, 29 Jan 2011 22:34:12 +0100 [thread overview]
Message-ID: <874o8r8kdn.fsf@gnu.org> (raw)
In-Reply-To: 1296330082.8111.371.camel@vuurvlieg
Hi Jan,
Thanks for the report and patches!
Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
> To get guile-1.9.14 cross built for mingw, I re-updated gnulib
> to include socket-related modules (starting with accept here)
>
> gnulib-tool --import --dir=. --lib=libgnu --source-base=lib --m4-base=m4 --doc-base=doc --tests-base=tests --aux-dir=build-aux --libtool --macro-prefix=gl --no-vc-files alignof alloca-opt announce-gen autobuild byteswap canonicalize-lgpl duplocale environ extensions flock fpieee full-read full-write func gendocs getaddrinfo git-version-gen gitlog-to-changelog gnu-web-doc-update gnupload havelib iconv_open-utf inet_ntop inet_pton isinf isnan lib-symbol-versions lib-symbol-visibility libunistring locale maintainer-makefile nproc putenv stat-time stdlib strcase strftime striconveh string sys_stat verify version-etc-fsf vsnprintf warnings accept bind close connect getpeername getsockname getsockopt listen malloc malloca recv recv recvfrom send sendto setsockopt shutdown socket socket
s
OK, I’ll add them on the next Gnulib update (soon).
> and used the attached patches. Without this update you get things
> like
>
> .libs/socket.o:socket.c:(.text+0xc72): undefined reference to `_accept_used_without_requesting_gnulib_module_accept'
OK but all the modules listed after ‘accept’ above are needed too,
right?
> Another small gripe, this handy thing in configure.ac
>
> m4_esyscmd([build-aux/git-version-gen\
> .tarball-version\
> 's/^release_\([0-9][0-9]*\)-\([0-9][0-9]*\)-\([0-9][0-9]*\)/v\1.\2\.\3/g']),
>
> makes it tricky to patch configure.ac when working from a tarball
> release, I got
>
> $ autoreconf
> Usage: build-aux/git-version-gen $srcdir/.tarball-version
Hmm could it be that there was a typo? Here running ‘git-version-gen’
outside of a Git tree works fine:
$ guile/build-aux/git-version-gen .tarball-version s/foo/bar/
UNKNOWN
> From ed1507425da819363cc6592ee033076838c82051 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Sat, 29 Jan 2011 17:31:17 +0100
> Subject: [PATCH 1/4] Add dynamic relocation support, default off.
I’ll write about it separately.
> From 4aeb4bb48423d87001b598030afed0a2dc03e747 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Sat, 29 Jan 2011 19:42:46 +0100
> Subject: [PATCH 2/4] Use AC_CHECK_LIB rather than AC_LIB_HAVE_LINKFLAGS. Fixes cross configuring.
>
> AC_LIB_HAVE_LINKFLAGS blondly looks in $prefix etc. for libraries.
> Not only is that unnecessary, it also breaks cross building.
>
> Here's what config.log says:
>
> configure:33053: i686-mingw32-gcc -mms-bitfields -std=gnu99 -o conftest.exe -O2 -DHAVE_CONFIG_H=1 -I/home/janneke/vc/gub/target/mingw/build/guile-1.9.14 -I/home/janneke/vc/gub/target/mingw/root/usr/include -L/home/janneke/vc/gub/target/mingw/root/usr/lib -L/home/janneke/vc/gub/target/mingw/root/usr/bin -L/home/janneke/vc/gub/target/mingw/root/usr/lib/w32api conftest.c /usr/lib/libltdl.a /usr/lib/libdl.a >&5
> /tmp/cc5v8vq5.o:conftest.c:(.text+0x1e): undefined reference to `_lt_dlopenext'
>
> note that using -lltdl -ldl instead of /usr/lib/libltdl.a
> /usr/lib/libdl.la works fine.
Ouch. May I suggest reporting it to bug-gnulib@gnu.org? :-) I think
people there would be happy to provide an appropriate fix and we
wouldn’t even have to worry. ;-)
> From 90631baf616303e1a8983b3b1eca101f5c5ac0ac Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Sat, 29 Jan 2011 19:51:37 +0100
> Subject: [PATCH 3/4] When cross building, run GUILE_FOR_BUILD instead of just-built guile.
Applied.
> From a597cd2edd0ebe3341e435ad08af4450b43beb31 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Sat, 29 Jan 2011 19:52:39 +0100
> Subject: [PATCH 4/4] Mingw compile fixes.
[...]
> --- a/libguile/bdw-gc.h
> +++ b/libguile/bdw-gc.h
> @@ -30,7 +30,9 @@
> allocation. */
>
> # define GC_THREADS 1
> +#ifndef __MINGW32__
> # define GC_REDIRECT_TO_LOCAL 1
> +#endif /* __MINGW32__ */
Why?
> --- a/libguile/deprecated.c
> +++ b/libguile/deprecated.c
> @@ -1639,7 +1639,7 @@ scm_i_fluidp (SCM x)
> \f
> /* Networking. */
>
> -#ifdef HAVE_NETWORKING
> +#ifdef HAVE_IPV6
>
> SCM_DEFINE (scm_inet_aton, "inet-aton", 1, 0, 0,
> (SCM address),
> @@ -1674,7 +1674,7 @@ SCM_DEFINE (scm_inet_ntoa, "inet-ntoa", 1, 0, 0,
> }
> #undef FUNC_NAME
>
> -#endif /* HAVE_NETWORKING */
> +#endif /* HAVE_IPV6 */
Commit e91f21dc1093dc7be139f99d211edee01a64705f should fix it,
differently.
> --- a/libguile/filesys.c
> +++ b/libguile/filesys.c
> @@ -523,7 +523,7 @@ static int fstat_Win32 (int fdes, struct stat *buf)
> /* Is this a socket ? */
> if (getsockopt (fdes, SOL_SOCKET, SO_ERROR, (void *) &error, &optlen) >= 0)
> {
> - buf->st_mode = _S_IFSOCK | _S_IREAD | _S_IWRITE | _S_IEXEC;
> + buf->st_mode = _S_IREAD | _S_IWRITE | _S_IEXEC;
Why? Isn’t ‘_S_IFSOCK’ defined on all MinGW?
> --- a/libguile/net_db.c
> +++ b/libguile/net_db.c
> @@ -456,6 +456,7 @@ SCM_DEFINE (scm_setserv, "setserv", 0, 1, 0,
>
> SCM_SYMBOL (sym_getaddrinfo_error, "getaddrinfo-error");
>
> +#ifndef __MINGW32__
> /* Make sure the `AI_*' flags can be stored as INUMs. */
> verify (SCM_I_INUM (SCM_I_MAKINUM (AI_ALL)) == AI_ALL);
Does MinGW lack getaddrinfo?
Gnulib’s ‘getaddrinfo’ module, which we use, is supposed to take care of
this, i.e., it should fall back to ‘gethostbyname’ if needed.
> --- a/libguile/ports.h
> +++ b/libguile/ports.h
> @@ -26,6 +26,7 @@
>
> #include "libguile/__scm.h"
>
> +#include <unistd.h>
Applied.
> --- a/libguile/socket.c
> +++ b/libguile/socket.c
> @@ -40,6 +40,7 @@
>
> #ifdef __MINGW32__
> #include "win32-socket.h"
> +#include <netdb.h>
> #endif
>
> #ifdef HAVE_STDINT_H
Applied.
Thanks!
Ludo’.
next prev parent reply other threads:[~2011-01-29 21:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-29 19:41 cross building 1.9.14 for mingw Jan Nieuwenhuizen
2011-01-29 21:34 ` Ludovic Courtès [this message]
2011-01-31 20:16 ` Jan Nieuwenhuizen
2011-01-31 20:44 ` Ludovic Courtès
2011-02-15 10:20 ` Jan Nieuwenhuizen
2011-02-22 8:34 ` Andy Wingo
2011-02-24 9:39 ` Jan Nieuwenhuizen
2011-02-24 10:37 ` Ludovic Courtès
2011-03-04 11:11 ` problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw] Andy Wingo
2011-03-20 8:08 ` Jan Nieuwenhuizen
2011-03-20 8:21 ` Ralf Wildenhues
2011-03-20 8:34 ` Jan Nieuwenhuizen
2011-03-20 8:56 ` Ralf Wildenhues
2011-01-29 21:39 ` Relocatable installation Ludovic Courtès
2011-01-31 20:26 ` Jan Nieuwenhuizen
2011-01-31 20:50 ` Andy Wingo
2011-01-31 20:55 ` Jan Nieuwenhuizen
2011-01-31 21:30 ` Andy Wingo
2011-01-31 21:49 ` Jan Nieuwenhuizen
2011-01-31 21:00 ` Ludovic Courtès
2011-01-31 21:18 ` Jan Nieuwenhuizen
2011-01-31 22:09 ` Ludovic Courtès
2011-01-31 22:26 ` Jan Nieuwenhuizen
2011-02-14 12:29 ` cross building 1.9.14 for mingw Ludovic Courtès
2011-02-15 10:02 ` Jan Nieuwenhuizen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874o8r8kdn.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).