From: Andy Wingo <wingo@pobox.com>
To: Jan Schukat <shookie@email.de>
Cc: 13848@debbugs.gnu.org
Subject: bug#13848: Statically linking guile-2.0.
Date: Sat, 09 Mar 2013 10:32:32 +0100 [thread overview]
Message-ID: <87d2v85367.fsf@pobox.com> (raw)
In-Reply-To: <5130D52F.3000704@email.de> (Jan Schukat's message of "Fri, 01 Mar 2013 17:19:59 +0100")
Hi,
On Fri 01 Mar 2013 17:19, Jan Schukat <shookie@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/
next prev parent reply other threads:[~2013-03-09 9:32 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 16:19 bug#13848: Statically linking guile-2.0 Jan Schukat
2013-03-02 15:28 ` Ludovic Courtès
2013-03-03 23:20 ` Jan Schukat
2013-03-05 0:54 ` Jan Schukat
2013-03-05 10:22 ` Ludovic Courtès
2013-03-05 15:44 ` Jan Schukat
2013-03-05 17:25 ` Ludovic Courtès
2013-03-05 22:25 ` Jan Schukat
2013-03-06 23:12 ` Ludovic Courtès
2013-03-09 13:44 ` Jan Schukat
2013-03-09 23:06 ` Andy Wingo
2013-03-09 23:57 ` shookie
2013-03-10 4:09 ` shookie
2013-03-10 17:32 ` Andy Wingo
2013-03-10 18:54 ` shookie
2013-03-10 19:23 ` Andy Wingo
2013-03-10 21:17 ` shookie
2013-03-10 22:03 ` shookie
2013-03-10 22:53 ` Andy Wingo
2013-03-11 0:07 ` shookie
2013-03-11 1:43 ` shookie
2013-03-11 8:26 ` Andy Wingo
2013-03-11 9:30 ` shookie
2013-03-13 9:30 ` Andy Wingo
2013-03-13 19:04 ` bug#13848: Aw: " Jan Schukat
2013-03-16 1:36 ` Jan Schukat
2013-03-29 19:35 ` Ludovic Courtès
2013-03-30 0:20 ` Jan Schukat
2013-03-30 21:27 ` Ludovic Courtès
2013-04-05 23:14 ` Jan Schukat
2013-04-07 10:20 ` Ludovic Courtès
2013-04-07 16:20 ` bug#13848: Aw: " Jan Schukat
2013-04-07 18:22 ` Andy Wingo
2013-04-07 19:18 ` bug#13848: Aw: " Jan Schukat
2013-04-07 20:00 ` Ludovic Courtès
2013-04-07 21:06 ` bug#13848: Aw: " Jan Schukat
2013-04-08 7:48 ` Ludovic Courtès
2013-03-10 17:38 ` shookie
2013-03-10 17:38 ` shookie
2013-03-14 13:54 ` Ludovic Courtès
2013-03-09 9:32 ` Andy Wingo [this message]
2013-03-09 15:42 ` Jan Schukat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2v85367.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=13848@debbugs.gnu.org \
--cc=shookie@email.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).