Hi,
On Fri 01 Mar 2013 17:19, Jan Schukat <shoo...@email.de> writes:
> But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not
> sure how often it is tested by the developers.
Approximately never, unfortunately. However we have been improving it
recently, and cross-compiling from GNU systems to MinGW is done
occasionally.
I will mostly address concerns about cross-compiling. Note that you
should really be using Guile from stable-2.0 git and the latest MinGW.
The easiest way to do that is to install a Fedora 18 VM, because they
package mingw very well and are closest to upstream. I'm a Debian user
and that's what I did, FWIW. I haven't yet tried with Debian itself.
Also I would mention that dynamic linking should work on Windows, if all
your DLLs are in the same folder. But I am ignorant and maybe that
doesn't work.
> Also, when you link statically and the symbol resolving works
> differently, you have to go through some hoops to resolve boehm-gc
> symbols, despite the preprocessor guards: That concerns
> HAVE_GC_SET_FINALIZER_NOTIFIER, HAVE_GC_GET_HEAP_USAGE_SAFE,
> HAVE_GC_GET_FREE_SPACE_DIVISOR, HAVE_GC_SET_FINALIZE_ON_DEMAND. In guile
> there are statically defined fallbacks for the respective functions,
> that cause linker conflicts when statically linked. Those functions
> probably should be renamed completely to prevent this kind of problem.
Are you saying that symbols with internal, static linkage inside bdw-gc
conflict with static symbols inside Guile? This sounds like a
misconfiguration issue.
> Then there is also the old problem of the conflicting definitions of
> struct timespec on MinGW in time.h and pthreads.h.
FWIW I did not experience this in my cross-compile.
> The bug #13768 about scm_getpid being used in "--without-posix" builds I
> have sent already.
Fixed upstream; thanks.
> Also, on mingw the guile-tools/guild copy script can't deal with the
> .exe ending. I have to configure and make once with
> --program-suffix=.exe to create the proper script names and files, and
> then again without, so they can be copied. (or find and copy them by
> hand between builds)
Are you certain that the meta/guile and meta/guild scripts need the .exe
extension? They are not EXE files. MinGW should add on .exe to
programs like libguile/guile (NB: not meta/guile) as needed.
Also note that I just fixed a bug in meta/guile in which it was
referencing libguile/guile without the @EXEEXT@.
Basically I think --program-suffix is not what you want.
> But then on install (processing .texi files) guile.exe fails with this
> message:
>
> "Throw without catch before boot:
> Throw to key system-error with args ("canonicalize-path" "~A" ("No such
> file or directory") (2))Aborting.
This is fixed in git, I believe.
I think we're close. Can you give it another try? If needed I can
handle the autogen side of things and give you a freshly prepared
tarball.
Andy
--
http://wingolog.org/
