cross building 1.9.14 for mingw

cross building 1.9.14 for mingw

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Hi,

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 sockets

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'

when building for mingw.

The full cross build recipe is in GUB

    git://github.com/janneke/gub.git

in the guile-1.9 branch

    https://github.com/janneke/gub/blob/guile-1.9/gub/specs/guile.py

Of course, when cross building someone should verify that build and
host have the same endianess and word size.  This means that for
cross building on an x86_64 box, we'd probably need to build a 32-bits
guile too.

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
    configure.ac:39: error: AC_INIT should be called with package and version arguments
    /home/janneke/vc/gub/target/tools/root/usr/share/aclocal-1.10/init.m4:26: AM_INIT_AUTOMAKE is expanded from...
    configure.ac:39: the top level
    autom4te: /home/janneke/vc/gub/target/tools/root/usr/bin/m4 failed with exit status: 1

esp. because the README talks about ./autogen.sh which does not exist.


Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

[-- Attachment #2: 0001-Add-dynamic-relocation-support-default-off.patch --]
[-- Type: text/x-patch, Size: 4967 bytes --]

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.

2005-06-08  Jan Nieuwenhuizen  <janneke@gnu.org>

	* configure.in: Add --enable-relocation option.  Default off.

libguile/ ChangeLog

2005-06-09  Jan Nieuwenhuizen  <janneke@gnu.org>

	Experimental relocation patch.

	* load.c (scm_init_argv0_relocation)[ARGV0_RELOCATION]: New
	function.

	(scm_init_load_path)[ARGV0_RELOCATION]: Use it.

	* load.c (scm_c_argv0_relocation)[ARGV0_RELOCATION]:

	* guile.c (main)[ARGV0_RELOCATION]: Use it to append from
	executable location derived scm library directory.
	[__MINGW32__|__CYGWIN__]: Append directory of executable to PATH.
---
 configure.ac     |   12 +++++++++++
 libguile/guile.c |    3 ++
 libguile/load.c  |   58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libguile/load.h  |    4 +++
 4 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5c70aa8..5fa6cf4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1452,6 +1452,18 @@ GUILE_THREAD_LOCAL_STORAGE
 fi # with_threads=pthreads
 
 
+## Dynamic relocation, based on argv[0].
+reloc_p=no
+AC_ARG_ENABLE(relocation,
+    [  --enable-relocation     compile with dynamic relocation.  Default: off],
+    [reloc_p=$enableval])
+
+if test "$reloc_p" = "yes"; then
+   AC_DEFINE([ARGV0_RELOCATION], [1], [Dynamic relocation])
+   AC_DEFINE_UNQUOTED([PATH_SEPARATOR], "$PATH_SEPARATOR", [Path separator])
+   AC_DEFINE_UNQUOTED([GUILE_EFFECTIVE_VERSION], "$GUILE_EFFECTIVE_VERSION", [GUILE_EFFECTIVE_VERSION])
+fi # $reloc_b
+
 ## Cross building	
 if test "$cross_compiling" = "yes"; then
   AC_MSG_CHECKING(cc for build)
diff --git a/libguile/guile.c b/libguile/guile.c
index 6da547b..896adc4 100644
--- a/libguile/guile.c
+++ b/libguile/guile.c
@@ -67,6 +67,9 @@ inner_main (void *closure SCM_UNUSED, int argc, char **argv)
 int
 main (int argc, char **argv)
 {
+#if ARGV0_RELOCATION
+  scm_c_argv0_relocation (argv[0]);
+#endif /* ARGV0_RELOCATION */
   scm_boot_guile (argc, argv, inner_main, 0);
   return 0; /* never reached */
 }
diff --git a/libguile/load.c b/libguile/load.c
index cbf9dc0..c887810 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -234,6 +234,59 @@ SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0,
 }
 #undef FUNC_NAME
 
+#if ARGV0_RELOCATION
+#include "filesys.h"
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+#include "posix.h"
+#endif
+
+char const *global_argv0 = 0;
+
+void
+scm_c_argv0_relocation (char const *argv0)
+{
+  global_argv0 = argv0;
+}
+
+SCM
+scm_init_argv0_relocation (char const* argv0)
+{
+  SCM bindir = scm_dirname (scm_from_locale_string (argv0));
+  SCM prefix = scm_dirname (bindir);
+  SCM datadir = scm_string_append (scm_list_2 (prefix,
+					     scm_from_locale_string ("/share/guile/" GUILE_EFFECTIVE_VERSION)));
+  SCM libdir = scm_string_append (scm_list_2 (prefix,
+					     scm_from_locale_string ("/lib")));
+
+#if 0 /* def SYSV */
+  {
+    SCM path;
+    char *env = getenv ("LD_LIBRARY_PATH");
+    if (env)
+      path = scm_string_append (scm_list_3 (scm_from_locale_string (env),
+					    scm_from_locale_string (PATH_SEPARATOR),
+					    datadir));
+    else
+      path = libdir;
+    scm_putenv (scm_string_append (scm_list_2 (scm_from_locale_string ("LD_LIBRARY_PATH="), path)));
+  }
+#elif defined (__CYGWIN__) || defined (__MINGW32__)
+  {
+    SCM path;
+    char *env = getenv ("PATH");
+    if (env)
+      path = scm_string_append (scm_list_3 (scm_from_locale_string (env),
+					    scm_from_locale_string (PATH_SEPARATOR),
+					    bindir));
+    else
+      path = bindir;
+    scm_putenv (scm_string_append (scm_list_2 (scm_from_locale_string ("PATH="), path)));
+  }
+#endif /* __CYGWIN__ || __MINGW32__ */
+    
+  return scm_list_1 (datadir);
+}
+#endif /* ARGV0_RELOCATION */
 
 /* Initialize the global variable %load-path, given the value of the
    SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -304,6 +357,11 @@ scm_init_load_path ()
   if (env)
     cpath = scm_parse_path (scm_from_locale_string (env), cpath);
 
+#if ARGV0_RELOCATION
+  if (global_argv0)
+    path = scm_append (scm_list_2 (path, scm_init_argv0_relocation (global_argv0)));
+#endif /* __CYGWIN__ || __MINGW32__ */
+  
   *scm_loc_load_path = path;
   *scm_loc_load_compiled_path = cpath;
 }
diff --git a/libguile/load.h b/libguile/load.h
index d1afefb..d0f7543 100644
--- a/libguile/load.h
+++ b/libguile/load.h
@@ -27,6 +27,10 @@
 
 \f
 SCM_API SCM scm_parse_path (SCM path, SCM tail);
+#if ARGV0_RELOCATION
+SCM_API void scm_c_argv0_relocation (char const *argv0);
+SCM_API SCM scm_init_argv0_relocation (char const* argv0);
+#endif
 SCM_API SCM scm_primitive_load (SCM filename);
 SCM_API SCM scm_c_primitive_load (const char *filename);
 SCM_API SCM scm_sys_package_data_dir (void);
-- 
1.7.1


[-- Attachment #3: 0002-Use-AC_CHECK_LIB-rather-than-AC_LIB_HAVE_LINKFLAGS.-.patch --]
[-- Type: text/x-patch, Size: 2059 bytes --]

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.
---
 configure.ac |   11 ++---------
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5fa6cf4..0684e6b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -76,11 +76,7 @@ AC_LIBTOOL_DLOPEN
 AC_PROG_LIBTOOL
 
 dnl Check for libltdl.
-AC_LIB_HAVE_LINKFLAGS([ltdl], [], [#include <ltdl.h>],
-  [lt_dlopenext ("foo");])
-if test "x$HAVE_LIBLTDL" != "xyes"; then
-  AC_MSG_ERROR([GNU libltdl (Libtool) not found, see README.])
-fi
+AC_CHECK_LIB(ltdl, lt_dlopenext, [HAVE_LIBLTDL=yes AC_SUBST(HAVE_LIBLTDL) LTLIBLTDL="-lltdl" AC_SUBST(LTLIBLTDL)])
 
 AC_CHECK_PROG(have_makeinfo, makeinfo, yes, no)
 AM_CONDITIONAL(HAVE_MAKEINFO, test "$have_makeinfo" = yes)
@@ -854,10 +850,7 @@ fi
 
 
 dnl GMP tests
-AC_LIB_HAVE_LINKFLAGS([gmp],
-  [],
-  [#include <gmp.h>],
-  [mpz_import (0, 0, 0, 0, 0, 0, 0);])
+AC_CHECK_LIB(gmp, main, [HAVE_LIBGMP=yes AC_SUBST(HAVE_LIBGMP) LTLIBGMP="-lgmp" AC_SUBST(LTLIBGMP)])
 
 if test "x$HAVE_LIBGMP" != "xyes"; then
   AC_MSG_ERROR([GNU MP 4.1 or greater not found, see README])
-- 
1.7.1


[-- Attachment #4: 0003-When-cross-building-run-GUILE_FOR_BUILD-instead-of-j.patch --]
[-- Type: text/x-patch, Size: 767 bytes --]

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.

---
 meta/guile.in |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/meta/guile.in b/meta/guile.in
index d1ae0d4..5125827 100644
--- a/meta/guile.in
+++ b/meta/guile.in
@@ -45,7 +45,11 @@ XDG_CACHE_HOME=${top_builddir}/cache
 export XDG_CACHE_HOME
 
 # do it
-exec ${top_builddir}/meta/uninstalled-env $GUILE "$@"
+if test "@cross_compiling@" = "no"; then
+    exec ${top_builddir}/meta/uninstalled-env $GUILE "$@"
+else
+    exec @GUILE_FOR_BUILD@ "$@"
+fi
 
 # never reached
 exit 1
-- 
1.7.1


[-- Attachment #5: 0004-Mingw-compile-fixes.patch --]
[-- Type: text/x-patch, Size: 2895 bytes --]

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.

---
 libguile/bdw-gc.h     |    2 ++
 libguile/deprecated.c |    4 ++--
 libguile/filesys.c    |    2 +-
 libguile/net_db.c     |    3 +++
 libguile/ports.h      |    1 +
 libguile/socket.c     |    1 +
 6 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/libguile/bdw-gc.h b/libguile/bdw-gc.h
index 3adf99e..09e0662 100644
--- 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__ */
 
 #endif
 
diff --git a/libguile/deprecated.c b/libguile/deprecated.c
index e11d353..12a61f6 100644
--- 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 */
 
 \f
 void
diff --git a/libguile/filesys.c b/libguile/filesys.c
index 68d90d9..d6251a0 100644
--- 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;
       buf->st_nlink = 1;
       buf->st_atime = buf->st_ctime = buf->st_mtime = time (NULL);
       return 0;
diff --git a/libguile/net_db.c b/libguile/net_db.c
index 14722d5..a017921 100644
--- 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);
 
@@ -745,6 +746,8 @@ SCM_DEFINE (scm_gai_strerror, "gai-strerror", 1, 0, 0,
 }
 #undef FUNC_NAME
 
+#endif /* __MINGW32__ */
+
 /* TODO: Add a getnameinfo(3) wrapper.  */
 
 \f
diff --git a/libguile/ports.h b/libguile/ports.h
index 36289ef..7408b9b 100644
--- a/libguile/ports.h
+++ b/libguile/ports.h
@@ -26,6 +26,7 @@
 
 #include "libguile/__scm.h"
 
+#include <unistd.h>
 #include "libguile/print.h"
 #include "libguile/struct.h"
 #include "libguile/threads.h"
diff --git a/libguile/socket.c b/libguile/socket.c
index 9b1618f..301854e 100644
--- 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
-- 
1.7.1

Re: cross building 1.9.14 for mingw

[Ludovic Courtès]

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

Re: cross building 1.9.14 for mingw

[Jan Nieuwenhuizen]

Ludovic Courtès schreef op za 29-01-2011 om 22:34 [+0100]:

Hi Ludovic,

> OK but all the modules listed after ‘accept’ above are needed too,
> right?

Yes, sure.

> 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

Yes, does it also work when you change configure.ac and autoreconf?

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

Yes, hat would be nice.

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

I'm using gc-6.8 and cannot seem to build a version for Mingw that
includes GC_local_malloc -- that seems to be for linux pthreads only.

Removing this redirect to local, fixes these

    .libs/libguile_2.0_la-alist.o:alist.c:(.text+0x6bf): undefined reference to `_GC_local_malloc'

build errors.

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

I don't have in it my mingw-runtime-3.14.  If there's a newer version,
I've misses something and would like to hear it.

> > +#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?

No, it lacks the AI_* definitions.  I realise that you may not want
to include this just yet, although it "documents" my progress building
it for mingw.

> Gnulib’s ‘getaddrinfo’ module, which we use, is supposed to take care of
> this, i.e., it should fall back to ‘gethostbyname’ if needed.

Yes.

More bits in a new thread.

Thanks, greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: cross building 1.9.14 for mingw

[Ludovic Courtès]

Hi Jan,

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> Ludovic Courtès schreef op za 29-01-2011 om 22:34 [+0100]:

[...]

>> 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
>
> Yes, does it also work when you change configure.ac and autoreconf?

Well yes?

>> > --- 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?
>
> I'm using gc-6.8

Please use GC 7.x; older versions aren’t supported.

>> > -      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?
>
> I don't have in it my mingw-runtime-3.14.  If there's a newer version,
> I've misses something and would like to hear it.

I don’t know.  I’m asking because this bit is specifically in an #ifdef
__MINGW32__.

>> > +#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?
>
> No, it lacks the AI_* definitions.

Oh fun.  And how’s this supposed to be used?  :-)

> I realise that you may not want to include this just yet, although it
> "documents" my progress building it for mingw.

Yes, sure.

Thanks,
Ludo’.

Re: cross building 1.9.14 for mingw

[Jan Nieuwenhuizen]

Ludovic Courtès schreef op za 29-01-2011 om 22:34 [+0100]:

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

I did, and Bruno Haible does not really care about this brokenness
or about cross compiling; he throws the towel on fixing this and
defends it by arguing that there are more users with a broken
compiler/linker, installed in /usr, which must be helped to find libs
in /usr/lib, than there are cross build users who have a sane setup and 
suffer by this.

In fact he thinks it's a feature that configure breaks when you
"upgrade" from autoconf's AC_CHECK_LIB to gnulib's
AC_LIB_HAVE_LINKFLAGS.

So I would suggest to take my patch and not use AC_LIB_HAVE_LINKFLAGS,
and possibly work with Ralf Wildenhues from autotools to provide
any extra autoconf functionality in autoconf itself, rather than
working through gnulib.  Ralf does have a good understandng about
cross building.

Bruno suggests that cross build environments (or more accurately,
build environments that install in another or clean DESTDIR
than where the buildtools are), should now start using or introduce
special configure flags, so that what worked previously, now can
be fixed by a tedious manual process, he writes

   For example, gettext's "configure --help" contains:

  --without-libpth-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libiconv-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libintl-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libglib-2.0-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libcroco-0.6-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libunistring-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libxml2-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libncurses-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libtermcap-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libxcurses-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libcurses-prefix     don't search for PACKLIBS in includedir and libdir
  --without-libexpat-prefix     don't search for PACKLIBS in includedir and libdir

Greetings,

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: cross building 1.9.14 for mingw

[Andy Wingo]

Hi Jan,

Excuse the long quote here, but:

On Tue 15 Feb 2011 11:20, Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> Ludovic Courtès schreef op za 29-01-2011 om 22:34 [+0100]:
>
>> > 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.  ;-)
>
> I did, and Bruno Haible does not really care about this brokenness
> or about cross compiling;

That is a totally unfair characterization, Jan.  You met him in the
Hague and he did not seem particularly evil then :)

> he throws the towel on fixing this and
> defends it by arguing that there are more users with a broken
> compiler/linker, installed in /usr, which must be helped to find libs
> in /usr/lib, than there are cross build users who have a sane setup and 
> suffer by this.
>
> In fact he thinks it's a feature that configure breaks when you
> "upgrade" from autoconf's AC_CHECK_LIB to gnulib's
> AC_LIB_HAVE_LINKFLAGS.
>
> Bruno suggests that cross build environments (or more accurately,
> build environments that install in another or clean DESTDIR
> than where the buildtools are), should now start using or introduce
> special configure flags, so that what worked previously, now can
> be fixed by a tedious manual process, he writes
>
>    For example, gettext's "configure --help" contains:
>
>   --without-libpth-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libiconv-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libintl-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libglib-2.0-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libcroco-0.6-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libunistring-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libxml2-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libncurses-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libtermcap-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libxcurses-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libcurses-prefix     don't search for PACKLIBS in includedir and libdir
>   --without-libexpat-prefix     don't search for PACKLIBS in includedir and libdir

Have you noticed that Guile has similar flags?

    $ ./configure --help | grep without | grep -- -lib
      --without-libiconv-prefix     don't search for libiconv in includedir and libdir
      --without-libunistring-prefix     don't search for libunistring in includedir and libdir
      --without-libltdl-prefix     don't search for libltdl in includedir and libdir
      --without-libgmp-prefix     don't search for libgmp in includedir and libdir
      --without-libintl-prefix     don't search for libintl in includedir and libdir
      --without-libreadline-prefix     don't search for libreadline in includedir and libdir

To be honest I don't find it too onerous to have to set these flags when
compiling with DESTDIR.  Sure, it would be nicer if it were just one
flag, and perhaps we can fix that; but as you have perhaps seen in the
numerous discussions on bug-guile recently, it seems that
AC_LIB_HAVE_LINKFLAGS solves real problems.

People who cross-compile are a hardy breed, and less numerous than
normal folk.  If the outcome here is that you have to pass more
configure flags, but I have to deal with less mail on bug-guile, thus
actually letting me hack again (!), I will take AC_LIB_HAVE_LINKFLAGS
any day ;)

I appreciate the work that you are doing on MinGW.  It will be nice for
the oppressed denizens of Microsoft to have Guile relief.  So, ánimo,
peregrino: we'll get there yet.

Cheers,

Andy
-- 
http://wingolog.org/

Re: cross building 1.9.14 for mingw

[Jan Nieuwenhuizen]

Andy Wingo schreef op di 22-02-2011 om 09:34 [+0100]:

Hi Andy,

> Excuse the long quote here

No problem.

> > I did, and Bruno Haible does not really care about this brokenness
> > or about cross compiling;
> 
> That is a totally unfair characterization, Jan.  You met him in the
> Hague and he did not seem particularly evil then :)

Why, of course not.  Good point!

As anyone with some basic understanding of the human psyche can  
testify: any characterization that you make of someone or something 
says next to nothing about the subject, but -- if you catch yourself
doing it -- may tell you a whole lot about yourself.  Thanks for
catching me, I apologise for my behaviour and will have a good look
into the evil in me.

> Have you noticed that Guile has similar flags?

Yes, lots of packages have these; it's just that I always thought these
flags were for broken compilers or esoteric setups.  There are over 250
packages in GUB's cross build system, and until now, it has not been
necessary to specify --with-libFOO=$DESTDIR/usr/lib for any of those.

> To be honest I don't find it too onerous to have to set these flags when
> compiling with DESTDIR.  Sure, it would be nicer if it were just one
> flag, and perhaps we can fix that; but as you have perhaps seen in the
> numerous discussions on bug-guile recently, it seems that
> AC_LIB_HAVE_LINKFLAGS solves real problems.

I'm glad to hear that, at least it means that my cross build troubles
were for a good cause...  So now I need to look into the problems
that AC_LIB_HAVE_LINKFLAGS actually solves and see how to keep solving
them while not breaking zero-config DESTDIR-builds.

> People who cross-compile are a hardy breed, and less numerous than
> normal folk.  If the outcome here is that you have to pass more
> configure flags, but I have to deal with less mail on bug-guile, thus
> actually letting me hack again (!), I will take AC_LIB_HAVE_LINKFLAGS
> any day ;)

Haha!  Let me see if I understand you correctly: You are happy to get
less bug reports, which means more time to hack, even if it means that
cross build systems (such as mine) get more fragile and cross builders
will have to spend some of the time that you win, to maintain them?

Actually, this fits my idea that upstream time is most precious.  The
irony here, is that Han-Wen and I created GUB to give us more time
to hack: distribute turn-key binaries for everyone, so that we don't
have to deal with bug-reports of users trying to build from source.

To be serious, I had the dubious thought that what AC_LIB_HAVE_LINKFLAGS
was fixing by looking in /usr, must essentially be broken setups.
If that's the case, I would much rather see we find a way to fix
or prevent such broken setups, rather than trying to be smarter than
gcc and break well-behaved -- even if rarely used -- DESTDIR setups.

I realise that DESTDIR setups were not broken per se, but it was
considered a good trade-off to induce a maintenance burden to cross
builders because it would help users and upstream.

> I appreciate the work that you are doing on MinGW.  It will be nice for
> the oppressed denizens of Microsoft to have Guile relief.  So, ánimo,
> peregrino: we'll get there yet.

Thanks and yes, that's a helpful attitude.  Almost there...

Greetings, Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: cross building 1.9.14 for mingw

[Ludovic Courtès]

Hi!

BTW I added cross-compilation jobs to Hydra (the ‘xbuild_*’ things):

  http://hydra.nixos.org/jobset/gnu/guile-2-0/

The cross-MinGW one needs some love, but at least the cross-GNU one
works fine without special hacks.

Thanks,
Ludo’.

problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]

[Andy Wingo]

Hi Jan,

Apologies for the delay in the reply.

On Thu 24 Feb 2011 10:39, Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> Andy Wingo schreef op di 22-02-2011 om 09:34 [+0100]:
>
>> To be honest I don't find it too onerous to have to set these flags when
>> compiling with DESTDIR.  Sure, it would be nicer if it were just one
>> flag, and perhaps we can fix that; but as you have perhaps seen in the
>> numerous discussions on bug-guile recently, it seems that
>> AC_LIB_HAVE_LINKFLAGS solves real problems.
>
> I'm glad to hear that, at least it means that my cross build troubles
> were for a good cause...  So now I need to look into the problems
> that AC_LIB_HAVE_LINKFLAGS actually solves and see how to keep solving
> them while not breaking zero-config DESTDIR-builds.

Here is my understanding of the problems and solutions.

Let's say you are building and installing Guile on Fedora.  You download
the tarball, ./configure && make && make install, and voila.  You run
Guile and it works.  Sweet!

So now you follow the manual, and it says that you can build your own
Guile via:

 $ gcc -o simple-guile simple-guile.c $(pkg-config guile-2.0 --cflags --libs)

which in your case expands out to

 $ gcc -o simple-guile simple-guile.c -I/usr/local/include/guile/2.0 -L/usr/local/include -lguile-2.0

And it compiles and links.  Awesome.

However when you run the simple-guile it doesn't work:

 $ ./simple-guile
 error: could not find libguile-2.0.so

Why is this?  It's because in Fedora, /usr/local/lib is not in the
default runtime library search path.

If we were compiling on Debian this would work because /usr/local/lib is
in the default library search path, though we would see the issue if we
installed to (e.g.) /opt/guile.

If we were compiling on Mac OS X it would work fine because the linker
effectively adds -rpath for libraries not in the standard locations
(even the /opt/guile case).

Those of us that haven't linked anything on the command line in a while
probably haven't noticed, because we use libtool to do the linking, and
libtool will add -rpath when linking against libraries that are not in
your system run path.

It used to be that libtool always added -rpath, but distros complained
-- Debian for one -- and so now libtool only adds -rpath for libs that
are not going to a system path.

It seems that what libtool does is the right thing to do by default.
The problem is, you can't add the -rpath in guile-config or pkg-config
-- the right thing to do depends on the compiler you are using.  So you
have to check for that at configure-time.  That's what
AC_LIB_HAVE_LINKFLAGS does.  Given some link-time flags,
AC_LIB_HAVE_LINKFLAGS determines what flags will be needed such that the
library will be found at runtime.  It adds -rpath when linking against
libraries that are not in your system path.

This discussion about system paths usually includes /usr, so that's the
default behavior of AC_LIB_HAVE_LINKFLAGS.  But sometimes you don't want
AC_LIB_HAVE_LINKFLAGS to look there -- that is, when you have $DESTDIR
builds -- and so in that case there are all those
--without-PACKAGE-prefix arguments.

That's the problem that AC_LIB_HAVE_LINKFLAGS solves for normal
"configure && make && make install" users.  It can complicate $DESTDIR
builds a little, in that you have to add some more configure arguments,
but it's not that bad.

Peace,

Andy
-- 
http://wingolog.org/

Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]

[Jan Nieuwenhuizen]

Andy Wingo schreef op vr 04-03-2011 om 12:11 [+0100]:

Hi Andy,

[sorry for the long quote]

> Let's say you are building and installing Guile on Fedora.  You download
> the tarball, ./configure && make && make install, and voila.  You run
> Guile and it works.  Sweet!
> 
> So now you follow the manual, and it says that you can build your own
> Guile via:
> 
>  $ gcc -o simple-guile simple-guile.c $(pkg-config guile-2.0 --cflags --libs)
> 
> which in your case expands out to
> 
>  $ gcc -o simple-guile simple-guile.c -I/usr/local/include/guile/2.0 -L/usr/local/include -lguile-2.0
> 
> And it compiles and links.  Awesome.
> 
> However when you run the simple-guile it doesn't work:
> 
>  $ ./simple-guile
>  error: could not find libguile-2.0.so
> 
> Why is this?  It's because in Fedora, /usr/local/lib is not in the
> default runtime library search path.
> 
> If we were compiling on Debian this would work because /usr/local/lib is
> in the default library search path, though we would see the issue if we
> installed to (e.g.) /opt/guile.
> 
> If we were compiling on Mac OS X it would work fine because the linker
> effectively adds -rpath for libraries not in the standard locations
> (even the /opt/guile case).
> 
> Those of us that haven't linked anything on the command line in a while
> probably haven't noticed, because we use libtool to do the linking, and
> libtool will add -rpath when linking against libraries that are not in
> your system run path.
> 
> It used to be that libtool always added -rpath, but distros complained
> -- Debian for one -- and so now libtool only adds -rpath for libs that
> are not going to a system path.
> 
> It seems that what libtool does is the right thing to do by default.
> The problem is, you can't add the -rpath in guile-config or pkg-config
> -- the right thing to do depends on the compiler you are using.  So you
> have to check for that at configure-time.  That's what
> AC_LIB_HAVE_LINKFLAGS does.  Given some link-time flags,
> AC_LIB_HAVE_LINKFLAGS determines what flags will be needed such that the
> library will be found at runtime.  It adds -rpath when linking against
> libraries that are not in your system path.

This all makes perfect sense to me.  Thanks for the elaborate
explanation.

> This discussion about system paths usually includes /usr, so that's the
> default behavior of AC_LIB_HAVE_LINKFLAGS.  But sometimes you don't want
> AC_LIB_HAVE_LINKFLAGS to look there -- that is, when you have $DESTDIR
> builds -- and so in that case there are all those
> --without-PACKAGE-prefix arguments.

Right.  So, while AC_LIB_HAVE_LINKFLAGS breaks $DESTDIR compiles (from
a AC_CHECK_LIB-pov) by default, even those will work by the aid of
these extra options.

Now consider, I have ~250 packages in my small cross build suite
and I imagine that projects like openembedded have a factor 10 more.
If/when AC_LIB_HAVE_LINKFLAGS becomes more popular, every of these
packages needs its configure be amended with --with-libFOO-prefix=...,
--with-libBAR-prefix=...  While doable, it would be nice if this
could be prevented.

What is not clear to me, from your explanation above, is why
AC_LIB_HAVE_LINKFLAGS needs to look in /usr at configure/build 
time, and especially: why it needs to look in /usr before looking
in gcc's library search path.

If it only looked in /usr after looking in the library search path,
the impact on $DESTDIR builds would be smaller: only --without-libFOO
would have to be specified.

It would be nicer still if looking in /usr at compile/build time could
be turned off (from your use cases that seems to be possible), or
be turned off for $DESTDIR builds.  That could be done with a single
flag.  It would be perfect if we found a way to detect $DESTDIR
builds automagically, so that the --with/--without $DESTDIR option
would have a smart default.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]

[Ralf Wildenhues]

Hello,

* Jan Nieuwenhuizen wrote on Sun, Mar 20, 2011 at 09:08:20AM CET:
> It would be nicer still if looking in /usr at compile/build time could
> be turned off (from your use cases that seems to be possible), or
> be turned off for $DESTDIR builds.  That could be done with a single
> flag.  It would be perfect if we found a way to detect $DESTDIR
> builds automagically, so that the --with/--without $DESTDIR option
> would have a smart default.

Bruno already explained why it is not a good idea to let DESTDIR
be the indicator of whether to look in /usr or not.

But I agree with you that there *should* be a common indicator to turn
off looking in /usr.  I think it should be a generalization of the
recent --with-sysroot addition to Libtool (which stems from the much
older sysroot support in GCC).  Implementors please talk to Paolo
Bonzini about further ideas for this.

Thanks,
Ralf

Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]

[Jan Nieuwenhuizen]

Ralf Wildenhues schreef op zo 20-03-2011 om 09:21 [+0100]:

> Bruno already explained why it is not a good idea to let DESTDIR
> be the indicator of whether to look in /usr or not.

Ouch, I think I missed that.  Does someone have a pointer?
Also, why look in /usr before looking in gcc's library search path?
If we'd look in /usr last, $DESTDIR builds would most probably
not even need this --with-sysroot option and all would be happy?

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: problems solved by AC_LIB_HAVE_LINKFLAGS [was: cross building 1.9.14 for mingw]

[Ralf Wildenhues]

* Jan Nieuwenhuizen wrote on Sun, Mar 20, 2011 at 09:34:37AM CET:
> Ralf Wildenhues schreef op zo 20-03-2011 om 09:21 [+0100]:
> 
> > Bruno already explained why it is not a good idea to let DESTDIR
> > be the indicator of whether to look in /usr or not.
> 
> Ouch, I think I missed that.  Does someone have a pointer?

http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00010.html

> Also, why look in /usr before looking in gcc's library search path?
> If we'd look in /usr last, $DESTDIR builds would most probably
> not even need this --with-sysroot option and all would be happy?

I don't know which code makes your configure look in /usr early;
if there are any -L/usr/lib or -L/usr/lib64 instances on the link
command line or in what libtool generates, then that is usually an
error.  Otherwise, I'd hope that the macro looks in directories
specified with -L before any default ones; and using gcc's library
search path for the default ones sounds sensible, but allowing to prefix
all directories with a sysroot specified at configure time would still
be a very helpful improvement.

Arbitrary reordering of directories OTOH sounds like it would only lead
to more random breakage in other situations.

Cheers,
Ralf

Relocatable installation

[Ludovic Courtès]

Hi Jan,

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> 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.
>
> 2005-06-08  Jan Nieuwenhuizen  <janneke@gnu.org>
>
> 	* configure.in: Add --enable-relocation option.  Default off.
>
> libguile/ ChangeLog
>
> 2005-06-09  Jan Nieuwenhuizen  <janneke@gnu.org>
>
> 	Experimental relocation patch.
>
> 	* load.c (scm_init_argv0_relocation)[ARGV0_RELOCATION]: New
> 	function.
>
> 	(scm_init_load_path)[ARGV0_RELOCATION]: Use it.
>
> 	* load.c (scm_c_argv0_relocation)[ARGV0_RELOCATION]:
>
> 	* guile.c (main)[ARGV0_RELOCATION]: Use it to append from
> 	executable location derived scm library directory.
> 	[__MINGW32__|__CYGWIN__]: Append directory of executable to PATH.

I’m not sure about this patch.  My feeling is that it would take more
than this to allow Guile to be truly relocatable, e.g., all of
$GUILE_LOAD_PATH, $GUILE_LOAD_COMPILED_PATH, $LD_LIBRARY_PATH,
etc. would have to work.  And some of them are hardcoded in the binary,
as is usual with the GNU Build System.

Furthermore, I think all these paths cannot be reliably inferred from
argv[0].  For instance because libdir doesn’t have to be $bindir/../lib.
It doesn’t seem to fit well in the GNU software installation process.

Still I’d be glad to hear arguments for and against.  :-)

Thanks,
Ludo’.

Re: Relocatable installation

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

Ludovic Courtès schreef op za 29-01-2011 om 22:39 [+0100]:

Hi Ludovic,

> I’m not sure about this patch.  My feeling is that it would take more
> than this to allow Guile to be truly relocatable, e.g., all of
> $GUILE_LOAD_PATH, $GUILE_LOAD_COMPILED_PATH, $LD_LIBRARY_PATH,
> etc. would have to work.

I realised we need GUILE_LOAD_COMPILED_PATH too.  Added that
in this new patch.  I added a bit more explanation: this should
be used together with a sane -rpath $ORIGIN/../lib build.

> And some of them are hardcoded in the binary,
> as is usual with the GNU Build System.

Yes, that's why the new, argv0-based directories are prepended
to those paths.

> Furthermore, I think all these paths cannot be reliably inferred from
> argv[0].  For instance because libdir doesn’t have to be $bindir/../lib.
> It doesn’t seem to fit well in the GNU software installation process.

No, you can choose all kinds of freaky install directories.  However,
if you don't do that and use the normal, default directory structure,
this enables binary packages with guile that can be installed in
$HOME or on Windows in c:/Program Files/Whatever.

> Still I’d be glad to hear arguments for and against.  :-)

One argument for is that we've been using this in LilyPond binary
packages (for linux and windows) since 2005.

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

[-- Attachment #2: 0001-Add-dynamic-relocation-support-default-off.patch --]
[-- Type: text/x-patch, Size: 5287 bytes --]

From d93b5bd21e99cda017e1b2d7b459e453113fbfa6 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Mon, 31 Jan 2011 21:05:48 +0100
Subject: [PATCH] Add dynamic relocation support, default off.

Set PATH, GUILE_LOAD_PATH, GUILE_LOAD_COMPILED_PATH according to
location of the guile executable.  Using this together with
-rpath $ORIGIN/../lib and not changing the general installed
directory layout, this enables relocatable binary packages,
for use in $HOME or for Windows.

2005-06-08  Jan Nieuwenhuizen  <janneke@gnu.org>

    * configure.in: Add --enable-relocation option.  Default off.

libguile/ ChangeLog

2005-06-09  Jan Nieuwenhuizen  <janneke@gnu.org>

    Experimental relocation patch.

    * load.c (scm_init_argv0_relocation)[ARGV0_RELOCATION]: New
    function.

    (scm_init_load_path)[ARGV0_RELOCATION]: Use it.

    * load.c (scm_c_argv0_relocation)[ARGV0_RELOCATION]:

    * guile.c (main)[ARGV0_RELOCATION]: Use it to append from
    executable location derived scm library directory.
    [__MINGW32__|__CYGWIN__]: Append directory of executable to PATH.
---
 configure.ac     |   12 +++++++++++
 libguile/guile.c |    3 ++
 libguile/load.c  |   55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libguile/load.h  |    5 ++++
 4 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5c70aa8..5fa6cf4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1452,6 +1452,18 @@ GUILE_THREAD_LOCAL_STORAGE
 fi # with_threads=pthreads
 
 
+## Dynamic relocation, based on argv[0].
+reloc_p=no
+AC_ARG_ENABLE(relocation,
+    [  --enable-relocation     compile with dynamic relocation.  Default: off],
+    [reloc_p=$enableval])
+
+if test "$reloc_p" = "yes"; then
+   AC_DEFINE([ARGV0_RELOCATION], [1], [Dynamic relocation])
+   AC_DEFINE_UNQUOTED([PATH_SEPARATOR], "$PATH_SEPARATOR", [Path separator])
+   AC_DEFINE_UNQUOTED([GUILE_EFFECTIVE_VERSION], "$GUILE_EFFECTIVE_VERSION", [GUILE_EFFECTIVE_VERSION])
+fi # $reloc_b
+
 ## Cross building	
 if test "$cross_compiling" = "yes"; then
   AC_MSG_CHECKING(cc for build)
diff --git a/libguile/guile.c b/libguile/guile.c
index 6da547b..896adc4 100644
--- a/libguile/guile.c
+++ b/libguile/guile.c
@@ -67,6 +67,9 @@ inner_main (void *closure SCM_UNUSED, int argc, char **argv)
 int
 main (int argc, char **argv)
 {
+#if ARGV0_RELOCATION
+  scm_c_argv0_relocation (argv[0]);
+#endif /* ARGV0_RELOCATION */
   scm_boot_guile (argc, argv, inner_main, 0);
   return 0; /* never reached */
 }
diff --git a/libguile/load.c b/libguile/load.c
index cbf9dc0..9ad1008 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -234,6 +234,53 @@ SCM_DEFINE (scm_parse_path, "parse-path", 1, 1, 0,
 }
 #undef FUNC_NAME
 
+#if ARGV0_RELOCATION
+#include "filesys.h"
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+#include "posix.h"
+#endif
+
+char const *global_argv0 = 0;
+
+void
+scm_c_argv0_relocation (char const *argv0)
+{
+  global_argv0 = argv0;
+}
+
+SCM
+scm_init_argv0_relocation (char const* argv0)
+{
+  SCM bindir = scm_dirname (scm_from_locale_string (argv0));
+  SCM prefix = scm_dirname (bindir);
+  SCM datadir = scm_string_append (scm_list_2 (prefix,
+					     scm_from_locale_string ("/share/guile/" GUILE_EFFECTIVE_VERSION)));
+  SCM path;
+  char *env = getenv ("PATH");
+  if (env)
+    path = scm_string_append (scm_list_3 (bindir,
+					  scm_from_locale_string (env),
+					  scm_from_locale_string (PATH_SEPARATOR)));
+  else
+    path = bindir;
+  scm_putenv (scm_string_append (scm_list_2 (scm_from_locale_string ("PATH="), path)));
+
+  return scm_list_1 (datadir);
+}
+
+SCM
+scm_init_argv0_compiled_relocation (char const* argv0)
+{
+  SCM bindir = scm_dirname (scm_from_locale_string (argv0));
+  SCM prefix = scm_dirname (bindir);
+  SCM pkglibdir = scm_string_append (scm_list_2 (prefix,
+						 scm_from_locale_string ("/lib/guile")));
+  SCM ccachedir = scm_string_append (scm_list_2 (pkglibdir,
+						 scm_from_locale_string ("/" GUILE_EFFECTIVE_VERSION "/ccache")));
+
+  return scm_list_1 (ccachedir);
+}
+#endif /* ARGV0_RELOCATION */
 
 /* Initialize the global variable %load-path, given the value of the
    SCM_SITE_DIR and SCM_LIBRARY_DIR preprocessor symbols and the
@@ -304,6 +351,14 @@ scm_init_load_path ()
   if (env)
     cpath = scm_parse_path (scm_from_locale_string (env), cpath);
 
+#if ARGV0_RELOCATION
+  if (global_argv0)
+    {
+      path = scm_append (scm_list_2 (path, scm_init_argv0_relocation (global_argv0)));
+      cpath = scm_append (scm_list_2 (cpath, scm_init_argv0_compiled_relocation (global_argv0)));
+    }
+#endif /* __CYGWIN__ || __MINGW32__ */
+  
   *scm_loc_load_path = path;
   *scm_loc_load_compiled_path = cpath;
 }
diff --git a/libguile/load.h b/libguile/load.h
index d1afefb..ea29d3a 100644
--- a/libguile/load.h
+++ b/libguile/load.h
@@ -27,6 +27,11 @@
 
 \f
 SCM_API SCM scm_parse_path (SCM path, SCM tail);
+#if ARGV0_RELOCATION
+SCM_API void scm_c_argv0_relocation (char const *argv0);
+SCM_API SCM scm_init_argv0_relocation (char const* argv0);
+SCM_API SCM scm_init_argv0_compiled_relocation (char const* argv0);
+#endif
 SCM_API SCM scm_primitive_load (SCM filename);
 SCM_API SCM scm_c_primitive_load (const char *filename);
 SCM_API SCM scm_sys_package_data_dir (void);
-- 
1.7.1

Re: Relocatable installation

[Andy Wingo]

Heya Jan,

On Mon 31 Jan 2011 21:26, Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> I realised we need GUILE_LOAD_COMPILED_PATH too.  Added that
> in this new patch.  I added a bit more explanation: this should
> be used together with a sane -rpath $ORIGIN/../lib build.

What about the extensions paths?  Are all paths from libpath.h
relocatable?

Curiously yours,

Andy
-- 
http://wingolog.org/

Re: Relocatable installation

[Jan Nieuwenhuizen]

Andy Wingo schreef op ma 31-01-2011 om 21:50 [+0100]:

Hi Andy,

> What about the extensions paths?  Are all paths from libpath.h
> relocatable?
> 
> Curiously yours,

Good question, we [LilyPond installs] never needed/used those,
I guess.  I can imagine that more paths need to be added, this
was sufficient for guile-1.8, however.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: Relocatable installation

[Andy Wingo]

On Mon 31 Jan 2011 21:55, Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

>> What about the extensions paths?  Are all paths from libpath.h
>> relocatable?
>
> Good question, we [LilyPond installs] never needed/used those,
> I guess.  I can imagine that more paths need to be added, this
> was sufficient for guile-1.8, however.

May I suggest then a bit more rigor in the choice of paths.  What paths
does Guile use?  Are they entirely taken from argv0, or are they
hard-coded at build time?  I'm not opposed to relocatable builds, in
principle, but if you can move Guile around, then it needs to hard-code
no paths in it.

Regards,

Andy
-- 
http://wingolog.org/

Re: Relocatable installation

[Jan Nieuwenhuizen]

Andy Wingo schreef op ma 31-01-2011 om 22:30 [+0100]:

> May I suggest then a bit more rigor in the choice of paths.

Sure.

> What paths does Guile use?

Good question.  I'm rather new to 1.9 series.

> Are they entirely taken from argv0

The only thing this reloc patch takes from argv0 is BINDIR
and we assume that no other options are given to configure
than --prefix=/some/path [ie, not --libdir=/whole/other/path].

> , or are they hard-coded at build time?  

> I'm not opposed to relocatable builds, in
> principle, but if you can move Guile around, then it needs to hard-code
> no paths in it.

Well, either that or simply prepend the new, dynamically 
relocated paths.  Removing all hardcoded paths when using
relocation does make sense, though.  You can't pick-up
stuff from another hardcoded install.  Hmm.

Greetings,
Jan.


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: Relocatable installation

[Ludovic Courtès]

Hello!

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> Ludovic Courtès schreef op za 29-01-2011 om 22:39 [+0100]:

[...]

>> I’m not sure about this patch.  My feeling is that it would take more
>> than this to allow Guile to be truly relocatable, e.g., all of
>> $GUILE_LOAD_PATH, $GUILE_LOAD_COMPILED_PATH, $LD_LIBRARY_PATH,
>> etc. would have to work.
>
> I realised we need GUILE_LOAD_COMPILED_PATH too.  Added that
> in this new patch.  I added a bit more explanation: this should
> be used together with a sane -rpath $ORIGIN/../lib build.

Ooh, I see.  $ORIGIN is the trick that makes it possible.

Your patch lacks this RPATH magic, though.  Perhaps it should check
whether ‘-Wl,-rpath='$ORIGIN/../lib'’ works?  Is ‘-Wl,-z -Wl,origin’
needed as well when linking ‘guile’?

>> And some of them are hardcoded in the binary,
>> as is usual with the GNU Build System.
>
> Yes, that's why the new, argv0-based directories are prepended
> to those paths.

OK, understood.

>> Furthermore, I think all these paths cannot be reliably inferred from
>> argv[0].  For instance because libdir doesn’t have to be $bindir/../lib.
>> It doesn’t seem to fit well in the GNU software installation process.
>
> No, you can choose all kinds of freaky install directories.  However,
> if you don't do that and use the normal, default directory structure,
> this enables binary packages with guile that can be installed in
> $HOME or on Windows in c:/Program Files/Whatever.

Yes, that’s what I meant: it only works as long as users touch only
$prefix, not $libdir, $bindir, etc.

>> Still I’d be glad to hear arguments for and against.  :-)
>
> One argument for is that we've been using this in LilyPond binary
> packages (for linux and windows) since 2005.

Good point.  :-)

Then I have nothing against this option, as long as it’s off by default.

Thanks,
Ludo’.

Re: Relocatable installation

[Jan Nieuwenhuizen]

[cc: list]

Ludovic Courtès schreef op ma 31-01-2011 om 22:00 [+0100]:

Hi,

> Your patch lacks this RPATH magic, though.

Yes, we have that in our GUB cross build system.  Possibly this
is a thing/feature request for libtool.

> Perhaps it should check
> whether ‘-Wl,-rpath='$ORIGIN/../lib'’ works?

That would be a nice feature.  I expect that if you want to
use this, you should know what you're doing anyway...

>   Is ‘-Wl,-z -Wl,origin’
> needed as well when linking ‘guile’?

No, we only use

    -Wl,-rpath -Wl,'$'ORIGIN/../lib

We do that by postprocessing libtool, substituting the
hardcode_libdir_flag_spec, of course, something like:

  ([('^(hardcode_libdir_flag_spec)=".+"', 'hardcode_libdir_flag_spec="-Wl,-rpath -Wl,\\$libdir -Wl,-rpath -Wl,\'$\'ORIGIN/../lib -Wl,-rpath -Wl,/home/janneke/vc/gub/target/mingw/root/usr/lib"')], '/home/janneke/vc/gub/target/mingw/build/guile-1.9.14/libtool')

> Yes, that’s what I meant: it only works as long as users touch only
> $prefix, not $libdir, $bindir, etc.

Sure.  Dropping a binary package in a random place is a
common way to do exactly that.

> Then I have nothing against this option, as long as it’s off by default.

Great, thanks!

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: Relocatable installation

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Ludovic Courtès schreef op ma 31-01-2011 om 22:00 [+0100]:
>
> Hi,
>
>> Your patch lacks this RPATH magic, though.
>
> Yes, we have that in our GUB cross build system.  Possibly this
> is a thing/feature request for libtool.
>
>> Perhaps it should check
>> whether ‘-Wl,-rpath='$ORIGIN/../lib'’ works?
>
> That would be a nice feature.

I mean, if this feature goes in, then ‘configure’ should check whether
this incantation is supported (it may not work with combinations other
than GCC + GNU ld) and give up if it’s not.

When it’s supported, ‘libguile/guile’ should have it in its LDFLAGS.

Thanks,
Ludo’.

Re: Relocatable installation

[Jan Nieuwenhuizen]

Ludovic Courtès schreef op ma 31-01-2011 om 23:09 [+0100]:

> I mean, if this feature goes in, then ‘configure’ should check whether
> this incantation is supported (it may not work with combinations other
> than GCC + GNU ld) and give up if it’s not.

Yes, I understand.

> When it’s supported, ‘libguile/guile’ should have it in its LDFLAGS.

Right, that would be nice; relocation would be fully out of the box.
Still too scary (and unnecessary) to enable by default, imho.

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: cross building 1.9.14 for mingw

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

>     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

Done.

However, we don’t seem to be actually using the ‘sockets’ module: IIUC
we should include “sockets.h” somewhere and call ‘gl_sockets_startup’,
which we don’t do.  Am I missing something?

Thanks,
Ludo’.

Re: cross building 1.9.14 for mingw

[Jan Nieuwenhuizen]

Ludovic Courtès schreef op ma 14-02-2011 om 13:29 [+0100]:

> Done.

Thanks!

> However, we don’t seem to be actually using the ‘sockets’ module: IIUC
> we should include “sockets.h” somewhere and call ‘gl_sockets_startup’,
> which we don’t do.  Am I missing something?

It seems you're right, we do need "socket", but "socketS"
is not needed.

I haven't looked at runtime behaviour; if I remove socket
from this list, libguile does not link with gnulib:

    .libs/socket.o: In function `scm_socket':
    /home/janneke/vc/gub/target/mingw/src/guile-1.9.15/libguile/socket.c:439: undefined reference to `_socket_used_without_requesting_gnulib_module_socket'
    collect2: ld returned 1 exit status


Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl