Portability fixes for win32 cross compiling

Portability fixes for win32 cross compiling

[Volker Grabsch]

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

Dear Guile developers,

I recently added support for your great guile library to
the mingw-cross-env project. In order to make this work,
I had to perform some portability fixes.

I originally created the fixes for the latest stable version
(guile 1.8.7), but I ported them forward to your current
development version. See the attached patches.
(generated with "git format-patch origin/master..HEAD")

Note that this doesn't solve all issues. I wasn't able to
forward-port my corrections to libguile/__scm.h regarding
win32 cross compiling of a _static_ libguile. Well, I could
provide something, but I'm unable to test it, because I'm
stuck with another problem introduced in 1.9.x:

The "gen-scmconfig" script includes a mix of native and
cross headers, which goes horribly wrong when performing
win32 cross compiling. Is it really necessary to #include
the "uniconv.h" from the cross system and to provide corresponding
SCM_ICONVEH_* constants?

Another note, regarding my patch for the "pthread_att_get_stack"
check: I assumed that when in doubt (i.e. when cross-compiling),
it is safe to set "works=no". However, I'm not sure about
that. Maybe this feature is so common that one should assume
"works=yes" when cross-compiling.


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

[-- Attachment #2: 0001-add-pdcurses-to-the-list-of-termlibs.patch --]
[-- Type: text/x-diff, Size: 792 bytes --]

From 6a05429f8da76475b7fc03ad42d308b98f6b777b Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Thu, 15 Apr 2010 00:58:22 +0200
Subject: [PATCH] add pdcurses to the list of termlibs

---
 acinclude.m4 |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index 2f1466b..8cfe1d4 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -378,7 +378,7 @@ dnl
 dnl Check all the things needed by `guile-readline', the Readline
 dnl bindings.
 AC_DEFUN([GUILE_READLINE], [
-  for termlib in ncurses curses termcap terminfo termlib ; do
+  for termlib in ncurses curses termcap terminfo termlib pdcurses ; do
      AC_CHECK_LIB(${termlib}, [tgoto],
        [READLINE_LIBS="-l${termlib} $READLINE_LIBS"; break])
   done
-- 
1.5.6.5


[-- Attachment #3: 0002-don-t-run-the-pthread_att_get_stack-check-when-cross.patch --]
[-- Type: text/x-diff, Size: 992 bytes --]

From fc80796464b051294280bba5af8ee4c25bef7c70 Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Thu, 15 Apr 2010 01:01:23 +0200
Subject: [PATCH] don't run the pthread_att_get_stack check when cross compiling

---
 configure.ac |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 73a4bd2..c6f480a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1413,6 +1413,7 @@ if test "$with_threads" = pthreads; then
 AC_MSG_CHECKING(whether pthread_attr_getstack works for the main thread)
 old_CFLAGS="$CFLAGS"
 CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
+if test "$cross_compiling" = "no"; then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
 #if HAVE_PTHREAD_ATTR_GETSTACK
 #include <pthread.h>
@@ -1443,6 +1444,9 @@ int main ()
 AC_DEFINE([PTHREAD_ATTR_GETSTACK_WORKS], [1], [Define when pthread_att_get_stack works for the main thread])],
 [works=no],
 [])
+else
+works=no
+fi
 CFLAGS="$old_CFLAGS"
 AC_MSG_RESULT($works)
 
-- 
1.5.6.5

Re: Portability fixes for win32 cross compiling

[Mike Gran]

> From: Volker Grabsch vog@notjusthosting.com

> Is it really necessary to #include the 
> "uniconv.h" from the cross system and to provide corresponding
> SCM_ICONVEH_* 
> constants?

Probably not.  I doubt that the libunistring constants are going
to change upstream, so you could hack around it by hard-coding them.
Simple, and possibly risky should libunistring decide to change them.

Or, I suppose, we could write a function in strings.c to convert
SCM_ICONVEH constants to libunistring constants.  That might be
friendlier to your cross-build, but, that function would get called
very often.  Might be a slight performance hit.

Thanks,

Mike

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

Mike Gran <spk121@yahoo.com> schrieb:
> From: Volker Grabsch vog@notjusthosting.com
> > Is it really necessary to #include the 
> > "uniconv.h" from the cross system and to provide corresponding
> > SCM_ICONVEH_* constants?
> 
> Probably not.  I doubt that the libunistring constants are going
> to change upstream, so you could hack around it by hard-coding them.
> Simple, and possibly risky should libunistring decide to change them.

Since I'll probably support Guile in mingw-cross-env for a long
time, I'd like to find a solution that doesn't require such a
bad hack.

> Or, I suppose, we could write a function in strings.c to convert
> SCM_ICONVEH constants to libunistring constants.  That might be
> friendlier to your cross-build, but, that function would get called
> very often.  Might be a slight performance hit.

What about a read-only variable that is initialized on Guile
initialization or as an initialized constant?

Or, what about changing the generated code? Why does the generator
have to determine a number to be written into the generated code?
Instead, the generated "scmconfig.h" could contain code like this:

    #include <uniconv.h>

    ...

    #define SCM_ICONVEH_ERROR iconveh_error


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

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

Volker Grabsch <vog@notjusthosting.com> schrieb:
> Or, what about changing the generated code? Why does the generator
> have to determine a number to be written into the generated code?
> Instead, the generated "scmconfig.h" could contain code like this:
> 
>     #include <uniconv.h>
> 
>     ...
> 
>     #define SCM_ICONVEH_ERROR iconveh_error

Okay, I just implemented that approach and it seems to work fine.
There were several other issues I had to fix. Please have a look
at the attached patches (6 in total). All of them seem to be needed
to cross-compile guile for mingw32.

In the end, I'm struck with the following error that I don't
know how to fix.

It would be great if you could have a look at my patches, and if
you could either include them, or tell me what's wrong with them.


-------------------------------------------------------------------
i686-pc-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/.../i686-pc-mingw32/lib/libffi-3.0.9/include -I/.../i686-pc-mingw32/include -I/.../i686-pc-mingw32/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -I/.../i686-pc-mingw32/include -g -O2 -MT libguile_2.0_la-foreign.lo -MD -MP -MF .deps/libguile_2.0_la-foreign.Tpo -c foreign.c -o libguile_2.0_la-foreign.o
foreign.c: In function 'scm_foreign_to_bytevector':
foreign.c:252: error: 'SCM_FOREIGN_TYPE_void' undeclared (first use in this function)
foreign.c:252: error: (Each undeclared identifier is reported only once
foreign.c:252: error: for each function it appears in.)
foreign.c: In function 'scm_foreign_set_finalizer_x':
foreign.c:371: error: 'SCM_FOREIGN_TYPE_void' undeclared (first use in this function)
foreign.c: In function 'scm_make_foreign_function':
foreign.c:678: error: 'SCM_FOREIGN_TYPE_void' undeclared (first use in this function)
foreign.c: In function 'scm_i_foreign_call':
foreign.c:993: warning: implicit declaration of function 'alloca'
foreign.c:993: warning: incompatible implicit declaration of built-in function 'alloca'
make[3]: *** [libguile_2.0_la-foreign.lo] Error 1
make[3]: Leaving directory `/home/vog/mingw-cross-env/Guile/guile/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/vog/mingw-cross-env/Guile/guile/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/vog/mingw-cross-env/Guile/guile'
make: *** [all] Error 2
-------------------------------------------------------------------


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

[-- Attachment #2: 0001-add-pdcurses-to-the-list-of-termlibs.patch --]
[-- Type: text/x-diff, Size: 792 bytes --]

From 6a05429f8da76475b7fc03ad42d308b98f6b777b Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Thu, 15 Apr 2010 00:58:22 +0200
Subject: [PATCH] add pdcurses to the list of termlibs

---
 acinclude.m4 |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index 2f1466b..8cfe1d4 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -378,7 +378,7 @@ dnl
 dnl Check all the things needed by `guile-readline', the Readline
 dnl bindings.
 AC_DEFUN([GUILE_READLINE], [
-  for termlib in ncurses curses termcap terminfo termlib ; do
+  for termlib in ncurses curses termcap terminfo termlib pdcurses ; do
      AC_CHECK_LIB(${termlib}, [tgoto],
        [READLINE_LIBS="-l${termlib} $READLINE_LIBS"; break])
   done
-- 
1.5.6.5


[-- Attachment #3: 0002-don-t-run-the-pthread_att_get_stack-check-when-cross.patch --]
[-- Type: text/x-diff, Size: 992 bytes --]

From fc80796464b051294280bba5af8ee4c25bef7c70 Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Thu, 15 Apr 2010 01:01:23 +0200
Subject: [PATCH] don't run the pthread_att_get_stack check when cross compiling

---
 configure.ac |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 73a4bd2..c6f480a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1413,6 +1413,7 @@ if test "$with_threads" = pthreads; then
 AC_MSG_CHECKING(whether pthread_attr_getstack works for the main thread)
 old_CFLAGS="$CFLAGS"
 CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
+if test "$cross_compiling" = "no"; then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
 #if HAVE_PTHREAD_ATTR_GETSTACK
 #include <pthread.h>
@@ -1443,6 +1444,9 @@ int main ()
 AC_DEFINE([PTHREAD_ATTR_GETSTACK_WORKS], [1], [Define when pthread_att_get_stack works for the main thread])],
 [works=no],
 [])
+else
+works=no
+fi
 CFLAGS="$old_CFLAGS"
 AC_MSG_RESULT($works)
 
-- 
1.5.6.5


[-- Attachment #4: 0003-fix-gen-scmconfig-for-cross-compiling.patch --]
[-- Type: text/x-diff, Size: 2052 bytes --]

From 34323df112197162c2441ec248895814ea911c76 Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Wed, 21 Apr 2010 18:36:30 +0200
Subject: [PATCH] fix gen-scmconfig for cross compiling

---
 libguile/Makefile.am     |    2 +-
 libguile/gen-scmconfig.c |   10 ++++------
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/libguile/Makefile.am b/libguile/Makefile.am
index a841c9f..5b441ec 100644
--- a/libguile/Makefile.am
+++ b/libguile/Makefile.am
@@ -54,7 +54,7 @@ gen_scmconfig_SOURCES = gen-scmconfig.c
 ## For some reason, OBJEXT does not include the dot
 gen-scmconfig.$(OBJEXT): gen-scmconfig.c
 	if [ "$(cross_compiling)" = "yes" ]; then \
-		$(CC_FOR_BUILD) $(DEFS) $(DEFAULT_INCLUDES) $(AM_CPPFLAGS) -c -o $@ $<; \
+		$(CC_FOR_BUILD) $(DEFS) $(DEFAULT_INCLUDES) -DBUILDING_LIBGUILE=1 -I$(top_srcdir) -I$(top_builddir) -c -o $@ $<; \
 	else \
 		$(COMPILE) -c -o $@ $<; \
 	fi
diff --git a/libguile/gen-scmconfig.c b/libguile/gen-scmconfig.c
index 851578f..5a37c68 100644
--- a/libguile/gen-scmconfig.c
+++ b/libguile/gen-scmconfig.c
@@ -125,7 +125,6 @@
 
 #include <stdio.h>
 #include <string.h>
-#include <uniconv.h>
 
 #define pf printf
 
@@ -145,6 +144,7 @@ main (int argc, char *argv[])
     pf ("#include <stdint.h>\n");
   if (SCM_I_GSC_NEEDS_INTTYPES_H)
     pf ("#include <inttypes.h>\n");
+  pf ("#include <uniconv.h>\n");
 
 #ifdef HAVE_LIMITS_H
   pf ("#include <limits.h>\n");
@@ -423,11 +423,9 @@ main (int argc, char *argv[])
 
   pf ("\n");
   pf ("/* Constants from uniconv.h.  */\n");
-  pf ("#define SCM_ICONVEH_ERROR %d\n", (int) iconveh_error);
-  pf ("#define SCM_ICONVEH_QUESTION_MARK %d\n", 
-      (int) iconveh_question_mark);
-  pf ("#define SCM_ICONVEH_ESCAPE_SEQUENCE %d\n",
-      (int) iconveh_escape_sequence);  
+  pf ("#define SCM_ICONVEH_ERROR ((int) iconveh_error)\n");
+  pf ("#define SCM_ICONVEH_QUESTION_MARK ((int) iconveh_question_mark)\n");
+  pf ("#define SCM_ICONVEH_ESCAPE_SEQUENCE ((int) iconveh_escape_sequence)\n");
 
   printf ("#endif\n");
 
-- 
1.5.6.5


[-- Attachment #5: 0004-remove-an-unused-and-dangling-include-directive.patch --]
[-- Type: text/x-diff, Size: 628 bytes --]

From 6f2b554eb5cf6a5f580689b6418fbb28d7d42c7c Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Wed, 21 Apr 2010 18:45:49 +0200
Subject: [PATCH] remove an unused and dangling #include directive

---
 libguile/objcodes.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/libguile/objcodes.c b/libguile/objcodes.c
index 2931468..47f6f3a 100644
--- a/libguile/objcodes.c
+++ b/libguile/objcodes.c
@@ -23,7 +23,6 @@
 #include <string.h>
 #include <fcntl.h>
 #include <unistd.h>
-#include <sys/mman.h>
 #include <sys/stat.h>
 #include <sys/types.h>
 #include <assert.h>
-- 
1.5.6.5


[-- Attachment #6: 0005-don-t-fail-when-HAVE_STAT64-is-undefined.patch --]
[-- Type: text/x-diff, Size: 642 bytes --]

From 2e30b23bd88dd5521ca87c920381999ed4e041c3 Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Wed, 21 Apr 2010 18:47:51 +0200
Subject: [PATCH] don't fail when HAVE_STAT64 is undefined

---
 libguile/_scm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libguile/_scm.h b/libguile/_scm.h
index a1884ca..ceca71a 100644
--- a/libguile/_scm.h
+++ b/libguile/_scm.h
@@ -119,7 +119,7 @@
 
 
 
-#if GUILE_USE_64_CALLS && HAVE_STAT64
+#if GUILE_USE_64_CALLS && defined(HAVE_STAT64)
 #define CHOOSE_LARGEFILE(foo,foo64)     foo64
 #else
 #define CHOOSE_LARGEFILE(foo,foo64)     foo
-- 
1.5.6.5


[-- Attachment #7: 0006-disable-thread-redirects-of-bdw-gc.patch --]
[-- Type: text/x-diff, Size: 585 bytes --]

From a9125a364c838c1bad2f3e2b153f7564b6502fc9 Mon Sep 17 00:00:00 2001
From: Volker Grabsch <vog@notjusthosting.com>
Date: Wed, 21 Apr 2010 19:52:37 +0200
Subject: [PATCH] disable thread redirects of bdw-gc

---
 libguile/bdw-gc.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libguile/bdw-gc.h b/libguile/bdw-gc.h
index 3adf99e..9780737 100644
--- a/libguile/bdw-gc.h
+++ b/libguile/bdw-gc.h
@@ -34,6 +34,8 @@
 
 #endif
 
+#define GC_NO_THREAD_REDIRECTS
+
 #include <gc/gc.h>
 
 #if (! ((defined GC_VERSION_MAJOR) && (GC_VERSION_MAJOR >= 7)))
-- 
1.5.6.5

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

Volker Grabsch <vog@notjusthosting.com> schrieb:
> Okay, I just implemented that approach and it seems to work fine.
> There were several other issues I had to fix. Please have a look
> at the attached patches (6 in total). All of them seem to be needed
> to cross-compile guile for mingw32.

Although I wan't able to fully solve all issues, my patches
solved a lot of them. It would be really helpful if you could
include (most of) them, as this would simplify things for
anyone who'd like to finish my work.

Or aren't you interested in restoring the ability of Guile
to work with cross-compilers?


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: Portability fixes for win32 cross compiling

[Greg Troxel]

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


Volker Grabsch <vog@notjusthosting.com> writes:

> Volker Grabsch <vog@notjusthosting.com> schrieb:
>> Okay, I just implemented that approach and it seems to work fine.
>> There were several other issues I had to fix. Please have a look
>> at the attached patches (6 in total). All of them seem to be needed
>> to cross-compile guile for mingw32.
>
> Although I wan't able to fully solve all issues, my patches
> solved a lot of them. It would be really helpful if you could
> include (most of) them, as this would simplify things for
> anyone who'd like to finish my work.
>
> Or aren't you interested in restoring the ability of Guile
> to work with cross-compilers?

I haven't looked at your patches, but +1 for guile being cross buildable.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: Portability fixes for win32 cross compiling

[Andy Wingo]

Hi Volker,

I had your messages starred as needing attention, and was silently
hoping Ludovic would deal with them. I'm sure he did the same, but in
reverse ;-)

Your patches look good, except for one. 

On Wed 21 Apr 2010 22:22, Volker Grabsch <vog@notjusthosting.com> writes:

> --- a/libguile/bdw-gc.h
> +++ b/libguile/bdw-gc.h
> @@ -34,6 +34,8 @@
>  
>  #endif
>  
> +#define GC_NO_THREAD_REDIRECTS
> +
>  #include <gc/gc.h>

Why did you do this?

In the future it will make it easier for me to apply these if they
follow our changelogging standards :) See any of the commits in Guile
for examples of the format.

Cheers,

Andy
-- 
http://wingolog.org/

Re: Portability fixes for win32 cross compiling

[Ludovic Courtès]

Hey!

Andy Wingo <wingo@pobox.com> writes:

> In the future it will make it easier for me to apply these if they
> follow our changelogging standards :) See any of the commits in Guile
> for examples of the format.

Or rather see info "(standards) Change Logs".  :-)

Ludo’.

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

Andy Wingo <wingo@pobox.com> schrieb:
> Your patches look good, except for one. 
> 
> On Wed 21 Apr 2010 22:22, Volker Grabsch <vog@notjusthosting.com> writes:
> 
> > --- a/libguile/bdw-gc.h
> > +++ b/libguile/bdw-gc.h
> > @@ -34,6 +34,8 @@
> >  
> >  #endif
> >  
> > +#define GC_NO_THREAD_REDIRECTS
> > +
> >  #include <gc/gc.h>
> 
> Why did you do this?

The GC thread redirects causes some compiling errors, so I
disabled them. I didn't digg further into that. Maybe there's
a better solution.

Since the patches are mostly independent from each other, I
think it is okay to ignore that patch and commit just the
other ones. Regarding the MinGW issues, there's more work to
be done anyway.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: Portability fixes for win32 cross compiling

[Ludovic Courtès]

Hi Volker,

I’m finally in the process of reviewing and applying your patches.

Volker Grabsch <vog@notjusthosting.com> writes:

> From 6f2b554eb5cf6a5f580689b6418fbb28d7d42c7c Mon Sep 17 00:00:00 2001
> From: Volker Grabsch <vog@notjusthosting.com>
> Date: Wed, 21 Apr 2010 18:45:49 +0200
> Subject: [PATCH] remove an unused and dangling #include directive
>
> ---
>  libguile/objcodes.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/libguile/objcodes.c b/libguile/objcodes.c
> index 2931468..47f6f3a 100644
> --- a/libguile/objcodes.c
> +++ b/libguile/objcodes.c
> @@ -23,7 +23,6 @@
>  #include <string.h>
>  #include <fcntl.h>
>  #include <unistd.h>
> -#include <sys/mman.h>
>  #include <sys/stat.h>
>  #include <sys/types.h>
>  #include <assert.h>

This one is wrong: the file uses mmap(3), which is declared in
<sys/mman.h> according to
<http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html>.

This function is missing on MinGW, though, but there’s currently no
replacement in Guile.  Would you like to work on it?

Thanks,
Ludo’.

Re: Portability fixes for win32 cross compiling

[Ludovic Courtès]

Hi!

Volker Grabsch <vog@notjusthosting.com> writes:

> The "gen-scmconfig" script includes a mix of native and
> cross headers, which goes horribly wrong when performing
> win32 cross compiling.

What happens exactly?

> Is it really necessary to #include
> the "uniconv.h" from the cross system and to provide corresponding
> SCM_ICONVEH_* constants?

The idea is to avoid including libunistring headers in public Guile
headers, so that the dependency on libunistring isn’t visible from the
outside.

Perhaps we could extract the values in some other way, but I’d like to
make sure I understand the problem before attempting something.

Thanks,
Ludo’.

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

Ludovic Courtès <ludo@gnu.org> schrieb:
> Volker Grabsch <vog@notjusthosting.com> writes:
> 
> > The "gen-scmconfig" script includes a mix of native and
> > cross headers, which goes horribly wrong when performing
> > win32 cross compiling.
> 
> What happens exactly?

I don't think that the exact error messages are relevant here
(some conflicting definitions of various symbols and types,
 resulting in various compiling errors),

because this is a general thing: You can't expect such a mix
of headers to work properly.

More concretely, when building "gen-scmconfig" with the native
compiler, you can only expect the native headers to be available,
not the cross headers. Well, the cross headers _are_ available,
but only because you add their include paths via "-I", which is
certainly not a sensible thing to do: You force the native compiler
to include headers written to be used by the cross compiler. You
simply can't expect that to work. Don't #include cross headers in
a native build.

> > Is it really necessary to #include
> > the "uniconv.h" from the cross system and to provide corresponding
> > SCM_ICONVEH_* constants?
> 
> The idea is to avoid including libunistring headers in public Guile
> headers, so that the dependency on libunistring isn’t visible from the
> outside.
> 
> Perhaps we could extract the values in some other way, but I’d like to
> make sure I understand the problem before attempting something.

I hope my explainations above help to make the issues more clear.

BTW, you can easily reproduce the issues by installing "Mingw-cross-env"
on your system, if you like.   http://mingw-cross-env.nongnu.org/#tutorial


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

Ludovic Courtès <ludo@gnu.org> schrieb:
> Volker Grabsch <vog@notjusthosting.com> writes:
> >
> > --- a/libguile/objcodes.c
> > +++ b/libguile/objcodes.c
> > @@ -23,7 +23,6 @@
> >  #include <string.h>
> >  #include <fcntl.h>
> >  #include <unistd.h>
> > -#include <sys/mman.h>
> >  #include <sys/stat.h>
> >  #include <sys/types.h>
> >  #include <assert.h>
> 
> This one is wrong: the file uses mmap(3), which is declared in
> <sys/mman.h> according to
> <http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html>.
> 
> This function is missing on MinGW, though, but there’s currently no
> replacement in Guile.  Would you like to work on it?

Sorry, I don't think I'm able to do that.

However, I remember that Guile might already contain some
alternative code for that, because objcodes.c finally compiled
after removing that #include directive. So maybe it just needs
to be guarded into "#if"?

    ...
    #include <unistd.h>
    #if _POSIX_MAPPED_FILES > 0
        #include <sys/mman.h>
    #endif
    #include <sys/stat.h>
    ...


BTW, a simple

    ...
    #ifdef _POSIX_MAPPED_FILES
        ...

seems to be sufficient under MinGW, too.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: Portability fixes for win32 cross compiling

[Ludovic Courtès]

Hi,

Volker Grabsch <vog@notjusthosting.com> writes:

> Ludovic Courtès <ludo@gnu.org> schrieb:
>> Volker Grabsch <vog@notjusthosting.com> writes:
>> >
>> > --- a/libguile/objcodes.c
>> > +++ b/libguile/objcodes.c
>> > @@ -23,7 +23,6 @@
>> >  #include <string.h>
>> >  #include <fcntl.h>
>> >  #include <unistd.h>
>> > -#include <sys/mman.h>
>> >  #include <sys/stat.h>
>> >  #include <sys/types.h>
>> >  #include <assert.h>
>> 
>> This one is wrong: the file uses mmap(3), which is declared in
>> <sys/mman.h> according to
>> <http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html>.
>> 
>> This function is missing on MinGW, though, but there’s currently no
>> replacement in Guile.  Would you like to work on it?
>
> Sorry, I don't think I'm able to do that.
>
> However, I remember that Guile might already contain some
> alternative code for that, because objcodes.c finally compiled
> after removing that #include directive.

Hmm AFAICS the mmap() call in there is unconditional.

Thanks,
Ludo’.

Re: Portability fixes for win32 cross compiling

[No Itisnt]

>> This one is wrong: the file uses mmap(3), which is declared in
>> <sys/mman.h> according to
>> <http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html>.
>>
>> This function is missing on MinGW, though, but there’s currently no
>> replacement in Guile.  Would you like to work on it?
>
> Sorry, I don't think I'm able to do that.

Try <http://msdn.microsoft.com/en-us/library/aa366556(VS.85).aspx> for
Windows' mmap equivalent. You could also just write a generic
fread/malloc equivalent, since the mmap is only for speed (I think).

Re: Portability fixes for win32 cross compiling

[Andy Wingo]

On Wed 09 Jun 2010 00:12, No Itisnt <theseaisinhere@gmail.com> writes:

>>> This one is wrong: the file uses mmap(3), which is declared in
>>> <sys/mman.h> according to
>>> <http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html>.
>>>
>>> This function is missing on MinGW, though, but there’s currently no
>>> replacement in Guile.  Would you like to work on it?
>>
>> Sorry, I don't think I'm able to do that.
>
> Try <http://msdn.microsoft.com/en-us/library/aa366556(VS.85).aspx> for
> Windows' mmap equivalent. You could also just write a generic
> fread/malloc equivalent, since the mmap is only for speed (I think).

It would be ideal if there were an mmap gnulib module, so we can
preserve the performance characteristics of mmap.

Andy
-- 
http://wingolog.org/

Re: Portability fixes for win32 cross compiling

[Volker Grabsch]

No Itisnt <theseaisinhere@gmail.com> schrieb:
> Volker Grabsch <vog@notjusthosting.com> writes:
> > Ludovic Courtès <ludo@gnu.org> schrieb:
> >>
> >> This one is wrong: the file uses mmap(3), which is declared in
> >> <sys/mman.h> according to
> >> <http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html>.
> >>
> >> This function is missing on MinGW, though, but there’s currently no
> >> replacement in Guile.  Would you like to work on it?
> >
> > Sorry, I don't think I'm able to do that.
> 
> Try <http://msdn.microsoft.com/en-us/library/aa366556(VS.85).aspx> for
> Windows' mmap equivalent. You could also just write a generic
> fread/malloc equivalent, since the mmap is only for speed (I think).

Sorry, but this is really going too far. It would be a different
thing if I was actually using Guile for Windows, but I don't have
any interest in doing that.

I'm just the maintainer of Mingw-cross-env who included Guile
on the request of a user. I fixed the latest Guile release to allow
for Windows cross compiling, which resulted in two small changes.

All I wanted to do was providing those two fixes to the Guile project
so that more people would profit from them. But I noticed that the
release was quite far behind the development version of Guile, so I
decided to port-forward my patches to make them more useful to you.

Porting the first change was straight-forward, but the second part
had to be fixed at another place in the dev version. And it still
didn't work, because the dev version contained many more non-portable
places which didn't exist in the release. I ended up fixig 6 places
in total, consuming a day rather than an hour of work. Then I gave
up and just sent the patches to you, assuming they would be useful
to you nevertheless.

Please, don't count on me on fixing anything more. I already helped
out more than I originally intended to do. I'm just the wrong guy
for that task.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR