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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Andy Wingo <wingo <at> pobox.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#13848: closed (Statically linking guile-2.0.)
Date: Wed, 13 Mar 2013 09:32:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 13 Mar 2013 10:30:41 +0100
with message-id <871ubjk5oe.fsf <at> pobox.com>
and subject line Re: bug#13848: Statically linking guile-2.0.
has caused the debbugs.gnu.org bug report #13848,
regarding Statically linking guile-2.0.
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
13848: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13848
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jan Schukat <shookie <at> email.de>
To: bug-guile <at> gnu.org
Subject: Statically linking guile-2.0.
Date: Fri, 01 Mar 2013 17:19:59 +0100

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

[Message part 3 (message/rfc822, inline)]

From: Andy Wingo <wingo <at> pobox.com>
To: shookie <at> email.de
Cc: Ludovic Courtès <ludo <at> gnu.org>, 13848-done <at> debbugs.gnu.org
Subject: Re: bug#13848: Statically linking guile-2.0.
Date: Wed, 13 Mar 2013 10:30:41 +0100

Hi,

On Mon 11 Mar 2013 10:30, shookie <at> email.de writes:

>   GUILEC scripts/autofrisk.go
> Backtrace:
> In ice-9/psyntax.scm:
> 1101: 19 [expand-top-sequence ((define (unglob pattern) (let # #))) () ...]
> 1259: 18 [#<procedure 21d8540 at ice-9/psyntax.scm:1067:36 ()>]
> 1605: 17 [expand-simple-lambda (# . #) () (()) ...]
> 1509: 16 [parse (((# #) . #(syntax-object # # #))) () () () () () ()]
> In ice-9/boot-9.scm:
>  627: 15 [map #<procedure 2205e10 at ice-9/psyntax.scm:1510:50 (x)> ((# . #))]
> In ice-9/psyntax.scm:
> 2114: 14 [expand-let (let # #) (# #) (# # #) ...]
> In ice-9/boot-9.scm:
>  627: 13 [map #<procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x)> (#)]
> In ice-9/psyntax.scm:
> 1257: 12 [#<procedure 2204ec0 at ice-9/psyntax.scm:2114:49 (x)> (open-input-pipe #)]
> 1186: 11 [syntax-type (open-input-pipe #) (# #) (# # #) ...]
>  579: 10 [syntax-type open-input-pipe (# #) (# # #) ...]
>  292: 9 [get-global-definition-hook open-input-pipe (hygiene scripts autofrisk)]
> In unknown file:
>    ?: 8 [module-variable #<directory (scripts autofrisk) 21a8dc8> open-input-pipe]
> In ice-9/boot-9.scm:
> 2790: 7 [b #<autoload (ice-9 popen) 21a86c0> open-input-pipe #f]
> 2579: 6 [#<procedure 1d76530 at ice-9/boot-9.scm:2567:4 (name #:optional autoload version #:key ensure)> # ...]
> 2850: 5 [try-module-autoload (ice-9 popen) #f]
> 2191: 4 [save-module-excursion #<procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()>]
> 2870: 3 [#<procedure 2205d20 at ice-9/boot-9.scm:2851:17 ()>]
> In unknown file:
>    ?: 2 [primitive-load-path "ice-9\\popen" ...]
>    ?: 1 [load-extension "libguile-2.0" "scm_init_popen"]
> In ice-9/boot-9.scm:
>  106: 0 [#<procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args)> misc-error ...]
> 
> ice-9/boot-9.scm:106:20: In procedure #<procedure 1f55340 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure dynamic-link: file: "libguile-2.0", message: "The specified module could not be found."
> make[3]: *** [scripts/autofrisk.go] Error 1

I believe I have fixed this one (and the scan-api one).  You will see a
warning when building these two files but that is all.  I think at this
point the build should complete.

New tarball:

  http://wingolog.org/priv/guile-2.0.7.194-dfd1d.tar.gz

This has been a very long bug report, but productive.  Thank you for
following through with these tests, and for checking the above tarball.

The next step, after moving on to actually build your application ;), is
to get the test suite working.  I suspect you will run into some issues.
Will you please run a make check -k, and send the resulting log (if it
has errors) to bug-guile <at> gnu.org?  Thanks :-) Please include
check-guile.log as well.

I'll close this report, in optimistic hope that these fixes do indeed
allow the build to complete.  Let me know how it goes, and happy hacking!

(Actually while I'm at it: would you also mail the complete set of
patches that you locally apply to your copy?  They'll be helpful in
future reports.  Thanks!)

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.