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

[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