GNU bug report logs - #13848
Statically linking guile-2.0.

Previous Next

Full log

Message #32 received at 13848 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Jan Schukat <shookie <at> email.de>
Cc: 13848 <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Sat, 09 Mar 2013 10:32:32 +0100

Hi,

On Fri 01 Mar 2013 17:19, Jan Schukat <shookie <at> 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/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.