[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW build fixes
From: |
Neil Jerram |
Subject: |
Re: MinGW build fixes |
Date: |
Sat, 27 Jun 2009 18:21:23 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
"carlo.bramix" <address@hidden> writes:
> Hello!
Hi Carlo!
>>> I don't understand why this fixes anything, since the `_ptr'
>>> variables are declared as `SCM_API' just like the non-`_ptr'
>>> variables.
>> Indeed. My guess is that it's because the DLL import/export
>> mechanism works for atomic data - i.e. chars, ints, pointers etc -
>> but not for structs.
>
> False. A DLL can export functions, variables, structures, unions and
> classes. After few fixes that I'm preparing to share, guile already
> compiles and it works perfectly in cygwin, which uses DLL too:
Great! I know there are already several emails from you that I
haven't responded to yet; please be assured that I do plan to.
> although it virtualizes a lot, cygwin cannot do miracles, it's always
> windows based and if you add -mno-cygwin it becames identical to
> mingw.
I think you mean when compiling in Cygwin, and that the -mno-cygwin is
a GCC flag; is that right?
> What we could suspect about it is the implementation of
> -export-dynamic under your mingw: which version are you using?
I'm using the MinGW cross compiler on GNU/Linux (Debian lenny):
address@hidden:~$ i586-mingw32msvc-gcc --version
i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
The configure invocation is:
CPPFLAGS=-I/usr/local/i586-mingw32msvc/include \
LDFLAGS=-L/usr/local/i586-mingw32msvc/lib \
GUILE_FOR_BUILD=/usr/local/bin/guile \
./configure --prefix=/usr/local/i586-mingw32msvc --host=i586-mingw32msvc
You can see the logs of my builds, for the Guile master and
branch_release-1-8 branches, at
http://www.ossau.uklinux.net/guile/snapshots, or at
http://autobuild.josefsson.org/guile/.
> I'm
> using the latest maintenance releases of gcc 3.4.5 and binutils
> 2.18.50 without troubles. Actually the troubles with mingw are
> elsewhere... may I ask how you made it working? Unless it has been
> committed recently, guile cannot be even compiled well because it is
> missing the support for CreateFileMapping(), plus other fixes around
> the code!
What version of Guile have you been trying to build? My attempt to
build the master branch (i.e. similar to the 1.9.0 pre-release)
currently fails at
./guile-snarf -o objcodes.x objcodes.c -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1
-I.. -I.. -I../lib -I../lib -I/usr/local/i586-mingw32msvc/include -g -O2
objcodes.c:26:22: error: sys/mman.h: No such file or directory
which I guess might be the same problem as "missing the support for
CreateFileMapping".
The branch_release-1-8 branch (i.e. similar to 1.8.x releases) seems
fine. though.
> Are you using another posix compatibility layer? But I
> could not see any change in your patch for configure script...
I hope my answers above cover this; let me know if not.
> Anyways, I would not corrupt guile because an isolated compiler bug
> (my opinion).
Worst case is that I'll put the MinGW changes in #ifdef __MINGW32__.
That's still corruption in a sense, but only a very little.
Regards,
Neil