From: Jan Schukat <shookie@email.de>
To: 13848@debbugs.gnu.org
Subject: bug#13848: Statically linking guile-2.0.
Date: Fri, 01 Mar 2013 17:19:59 +0100 [thread overview]
Message-ID: <5130D52F.3000704@email.de> (raw)
I'm trying to build a program that uses guile 2.0 on linux, windows and
osx and finds the same environment, more or less, on all 3 platforms.
That means mainly for windows reasons, I have to statically link it.
So, first step is a little test system to compile it everywhere.
But compiling guile-2.0 on MinGW is a very hairy undertaking. I'm not
sure how often it is tested by the developers.
First of all, You have to define a whole lot of environment variables.
For one, there is no pkg-config on windows, but ./configure --help tells
you what to do, so that's ok.
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.
Then there is also the old problem of the conflicting definitions of
struct timespec on MinGW in time.h and pthreads.h. I still have to
conditionally define it in stat-time.h and in thread.c - and I can't use
HAVE_STRUCT_TIMESPEC as a preprocessor check, it has to be
__TIMESPEC_DEFINED. Anything else leads to ugly conflicts, either
already at compile time or at link time. Most likely also related to
statically linking.
The bug #13768 about scm_getpid being used in "--without-posix" builds I
have sent already.
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)
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 application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information."
Calling guile.exe directly gives this message:
"Throw without catch before boot:
Throw to key misc-error with args ("primitive-load-path" "Unable to find
file ~S in load path" ("ice-9/boot-9") #f)Aborting.
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information."
When I copy the libguile and the header by hand and then I can build the
a program, which does nothing more but calling scm_with_guile and
scm_shell, get a popup window with the message:
"This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information."
So my guess is, that due to some weird path construction in automake (of
which the .exe copying trouble is just another symptom), the scheme
modules can't be found and built, and thus everything crashes at startup.
But trying to figure out what's going on and wrong in an automake build
is a major project of its own. Any hints by the experts?
Regards
Jan Schukat
next reply other threads:[~2013-03-01 16:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 16:19 Jan Schukat [this message]
2013-03-02 15:28 ` bug#13848: Statically linking guile-2.0 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
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=5130D52F.3000704@email.de \
--to=shookie@email.de \
--cc=13848@debbugs.gnu.org \
/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).