Re: Cross-compiling with mingw
Sylvain Beucler b...@beuc.net writes:
i586-mingw32msvc-gcc -I/usr/local/cross-tools/i386-mingw32msvc/include -g
-O2 -Wall -Wmissing-prototypes -Werror .libs/guile.exeS.o
-I/usr/local/cross-tools/i386-mingw32msvc/include -o guile.exe guile-guile.o
-Wl,--export-dynamic -L/usr/local/cross-tools/i386-mingw32msvc/lib
./.libs/libguile.a /usr/local/cross-tools/i386-mingw32msvc/lib/libgmp.a
-lws2_32 /usr/local/cross-tools/i386-mingw32msvc/lib/libltdl.dll.a
-L/usr/local/cross-tools/i386-mingw32msvc/lib
-L/usr/local/cross-tools/i386-mingw32msvc/lib
guile-guile.o: In function `main':
/usr/src/guile-1.8.5/libguile/guile.c:74: undefined reference to
`__imp__scm_boot_guile'
guile-guile.o: In function `inner_main':
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_options'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_language'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_result'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_output'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_output_length'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_maybe_valid_type_p'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_read'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_eval'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_print'
/usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to
`__imp__gdb_binding'
/usr/src/guile-1.8.5/libguile/guile.c:59: undefined reference to
`__imp__scm_shell'
collect2: ld returned 1 exit status
rm -f .libs/guile.exeS.o
make[3]: *** [guile.exe] Erreur 1
The area of import/export/visibility has moved on a bit since this
report, and the only troublesome bindings now are 3 gdb_* ones, which
we don't actually need. I've pushed the patch below, and hopefully
we'll now have a complete MinGW build (of branch_release-1-8).
Regards,
Neil
From 8510e39278161d3cbf8ec4ba87b123fe28763ed4 Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.uklinux.net
Date: Thu, 25 Jun 2009 21:40:32 +0100
Subject: [PATCH] Remove GDB_INTERFACE stuff from guile's main program
The main motivation for this is wanting a successful MinGW build,
which is currently failing with:
guile-guile.o: In function `inner_main':
/home/neil/SW/Guile/ovnight/libguile/guile.c:55: undefined reference to `__imp__gdb_result'
/home/neil/SW/Guile/ovnight/libguile/guile.c:55: undefined reference to `__imp__gdb_output'
/home/neil/SW/Guile/ovnight/libguile/guile.c:55: undefined reference to `__imp__gdb_output_length'
The detailed problem here is to do with how those variables are
declared as exported from the libguile DLL and imported by the guile.c
main program. But in fact we don't need to solve that problem because
the GDB interface is an idea that never actually happened. So here we
just remove the offending variable references from guile.c.
For the record, Guile contains two kinds of GDB support, one of which
is real (and works, last time I tried it), and the other mythical.
The first kind is that libguile includes the utility functions
gdb_print, gdb_eval, etc., and the variable gdb_output. These have no
purpose except for developers to use from GDB when debugging
something. For example, if you have a SCM x and want to know what it
is, you can do:
(gdb) call gdb_print(x)
(gdb) p gdb_output
The second kind is that those utility functions are somehow declared
to GDB, and then GDB itself uses/calls them in some useful way. This
was an interesting idea, but (AFAICT) never actually happened.
I think it's worth leaving gdb_interface.h in the repository and the
distribution, in case this idea is properly resurrected in the future.
* libguile/guile.c (top level): Remove GDB_INTERFACE declaration.
(inner_main): Remove GDB_INTERFACE_INIT call.
---
libguile/guile.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/libguile/guile.c b/libguile/guile.c
index c8341c2..3e01b57 100644
--- a/libguile/guile.c
+++ b/libguile/guile.c
@@ -40,11 +40,6 @@
#include winsock2.h
#endif
-/* Debugger interface (don't change the order of the following lines) */
-#define GDB_TYPE SCM
-#include libguile/gdb_interface.h
-GDB_INTERFACE;
-
static void
inner_main (void *closure SCM_UNUSED, int argc, char **argv)
{
@@ -52,7 +47,6 @@ inner_main (void *closure SCM_UNUSED, int argc, char **argv)
/* This is necessary to startup the Winsock API under Win32. */
WSADATA WSAData;
WSAStartup (0x0202, WSAData);
- GDB_INTERFACE_INIT;
#endif /* __MINGW32__ */
/* module initializations would go here */
--
1.5.6.5
Re: Cross-compiling with mingw
Next MinGW build issue: Sylvain Beucler b...@beuc.net writes: $ make [...] DLL_EXPORT -DPIC -o .libs/libguile_la-stime.o cc1: warnings being treated as errors stime.c:85: warning: ‘tzname’ redeclared without dllimport attribute: previous dllimport ignored I found 2 references to this issue: - http://cygwin.com/ml/cygwin/2008-01/msg00491.html = removed tzname - http://www.nabble.com/getdate-on-mingw:-tzname-problems-td14855896.html = use HAVE_DECL_TZNAME instead I used the 2nd option: # if !HAVE_DECL_TZNAME /* For SGI. */ extern char *tzname[]; /* RS6000 and others reject char **tzname. */ #endif #if defined (__MINGW32__) # define tzname _tzname #endif I don't understand this. The second half of this section implies that the MinGW build isn't going to reference a function called `tzname' anyway (because it's going to use `_tzname' instead). So why should a MinGW build want any declaration of `tzname' at all? And as far as a declaration of `_tzname' is concerned, there are no more #includes after this, so we must have already got a declaration of `_tzname' from one of the preceding includes. Hence, and taking care not to alter the !__MINGW32__ behaviour: #if defined (__MINGW32__) # define tzname _tzname #else #ifndef tzname /* For SGI. */ extern char *tzname[]; /* RS6000 and others reject char **tzname. */ #endif #endif This looks pretty clear and safe to me, so I'll push a commit straightaway and see if it works in the overnight MinGW build. Regards, Neil
Re: Cross-compiling with mingw
On Mon, May 26, 2008 at 10:43:44PM +0200, Sylvain Beucler wrote: Hi, I'm tring to cross-compile Guile from GNU/Linux with mingw (so I can statically build guile in a .exe without having to use that other OS). I cross-compiled gmp and libltdl (dependencies). Now I have a few troubles with guile: Act I) Configuration $ CPPFLAGS=-I/usr/local/cross-tools/i386-mingw32msvc/include \ LDFLAGS=-L/usr/local/cross-tools/i386-mingw32msvc/lib \ ./configure --host=i586-mingw32msvc --build=i686-pc-linux-gnu [...] checking for restartable system calls... configure: error: cannot run test program while cross compiling The problem apparently lies in configure.in, macro AC_SYS_RESTARTABLE_SYSCALLS Note that the autoconf documentation deprecates this macro: These days portable programs [...] should not rely on `HAVE_RESTARTABLE_SYSCALLS', since nowadays whether a system call is restartable is a dynamic issue, not a configuration-time issue. I commented it out for a start. Act II) Compilation $ make [...] DLL_EXPORT -DPIC -o .libs/libguile_la-stime.o cc1: warnings being treated as errors stime.c:85: warning: ‘tzname’ redeclared without dllimport attribute: previous dllimport ignored I found 2 references to this issue: - http://cygwin.com/ml/cygwin/2008-01/msg00491.html = removed tzname - http://www.nabble.com/getdate-on-mingw:-tzname-problems-td14855896.html = use HAVE_DECL_TZNAME instead I used the 2nd option: # if !HAVE_DECL_TZNAME /* For SGI. */ extern char *tzname[]; /* RS6000 and others reject char **tzname. */ #endif #if defined (__MINGW32__) # define tzname _tzname #endif Act III) Linking i586-mingw32msvc-gcc -I/usr/local/cross-tools/i386-mingw32msvc/include -g -O2 -Wall -Wmissing-prototypes -Werror .libs/guile.exeS.o -I/usr/local/cross-tools/i386-mingw32msvc/include -o guile.exe guile-guile.o -Wl,--export-dynamic -L/usr/local/cross-tools/i386-mingw32msvc/lib ./.libs/libguile.a /usr/local/cross-tools/i386-mingw32msvc/lib/libgmp.a -lws2_32 /usr/local/cross-tools/i386-mingw32msvc/lib/libltdl.dll.a -L/usr/local/cross-tools/i386-mingw32msvc/lib -L/usr/local/cross-tools/i386-mingw32msvc/lib guile-guile.o: In function `main': /usr/src/guile-1.8.5/libguile/guile.c:74: undefined reference to `__imp__scm_boot_guile' guile-guile.o: In function `inner_main': /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_options' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_language' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_result' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_output' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_output_length' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_maybe_valid_type_p' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_read' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_eval' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_print' /usr/src/guile-1.8.5/libguile/guile.c:55: undefined reference to `__imp__gdb_binding' /usr/src/guile-1.8.5/libguile/guile.c:59: undefined reference to `__imp__scm_shell' collect2: ld returned 1 exit status rm -f .libs/guile.exeS.o make[3]: *** [guile.exe] Erreur 1 Duh! I'm out of ideas. Help? :) This one is apparently due to guile.c: #ifdef __MINGW32__ # define SCM_IMPORT 1 #endif When the error occured, the build system was apparently using libguile.la statically. In this case, __declspec (dllimport) need not be used, and so SCM_IMPORT need not be defined, so the linker won't use the '__imp__' symbols. ( The goat book uses a slightly more complex technique to detect the use of DLL imports: http://sources.redhat.com/autobook/autobook/autobook_255.html # -- # Win32 objects need to tell the header whether they will be linking # with a dll or static archive in order that everything is imported # to the object in the same way that it was exported from the # archive (extern for static, __declspec(dllimport) for dlls) # -- LIBHELLO_DLL_IMPORT= case $host in *-*-cygwin* | *-*-mingw* ) if test X$enable_shared = Xyes; then AC_TRY_LINK_FUNC([libhello_is_dll], [LIBHELLO_DLL_IMPORT=-DLIBHELLO_DLL_IMPORT]) fi ;; esac AC_SUBST(LIBHELLO_DLL_IMPORT) and then: #ifdef _WIN32 # ifdef DLL_EXPORT #define HELLO_SCOPE __declspec(dllexport) # else #ifdef LIBHELLO_DLL_IMPORT # define HELLO_SCOPE extern __declspec(dllimport) #endif # endif #endif #ifndef HELLO_SCOPE # define HELLO_SCOPE extern #endif ) With the ./configure line I mentioned, I then ran in to problems linking
