On 03/09/2013 10:32 AM, Andy Wingo wrote: > Hi, > > On Fri 01 Mar 2013 17:19, Jan Schukat 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. Well, I really do my linux builds and most development on linux: that's the uname -a: Linux solon 3.5.0-26-generic #40-Ubuntu SMP Tue Feb 26 19:59:36 UTC 2013 i686 athlon i686 GNU/Linux My windows builds I really do on windows7/mingw, the uname -a there: MINGW32_NT-6.1 BIAS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys I haven't even tried to do any of that guile building on OSX, and as I understand cross-compiling from Linux to OSX is more or less impossible/a nightmare (the VLC guys do it though I think), so I will do it on my old iMac too. I really would like to do all 3 targets via cross compiles some day (especially since compilation on linux is the fastest by far), but for now I just want to get it to work and have something to build on. >> 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. That problem I really have on Linux too. I build my own gc for static linking, and I pass the relevant environment variables to configure (I don't rely in pkg-config, because it is not easily available on windows) .You should be able to reproduce it, with my little test project. But when I don't pass those CPP guards to configure, I get compile errors. >> 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. That's a very old and nasty problem with the pthread headers on windows. When I was searching I found people having problems with that for years and years. > >> 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. I guess You can really only reproduce that on windows, since that really has to do with how windows treats paths and executable file names. >> 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. I tried today with this tarball: http://hydra.nixos.org/build/4290536/download/3/guile-2.0.7.157-929d1.tar.gz Seems to have a gcc check error where a capital -V option is passed and it fails. Summary in previous email to this bug thread. > Andy I will keep trying of course. I can foresee a lot of problems with libreadline and similar loadable modules that use external dynamic libraries that don't come in a standard windows install on windows too. But I plan to make some changes/patches to the load paths anyway, so they work the same everywhere for my program, so I can address that there. But until then I first need to get something that properly builds everywhere reliably. Regards Jan Schukat