[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13848: Statically linking guile-2.0.

From: Jan Schukat
Subject: bug#13848: Statically linking guile-2.0.
Date: Sat, 09 Mar 2013 16:42:22 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3

On 03/09/2013 10:32 AM, Andy Wingo wrote:

On Fri 01 Mar 2013 17:19, Jan Schukat<address@hidden>  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

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
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 @address@hidden

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

"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
I tried today with this tarball: http://hydra.nixos.org/build/4290536/download/3/guile- 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.


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.


Jan Schukat

Attachment: guiletest.tgz
Description: application/compressed-tar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]