[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile Build Errors
From: |
Ludovic Courtès |
Subject: |
Re: Guile Build Errors |
Date: |
Wed, 02 Sep 2009 13:49:12 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Hi,
bornlibra23 <address@hidden> writes:
>> That means `load-extension' et al. won't work (we could use Libtool's
>> preopen magic to make it work with static libraries, but we currently
>> don't).
> Can you tell me which of the tests are expected to fail?
Sometimes modules load extensions with `load-extension', e.g., the
`(srfi srfi-1)' module. On systems supporting shared libs, this
corresponds to a dlopen(3) call, which just won't work when building
static libraries, as is the case on your system.
GNU Libtool's `-dlpreopen' can be used so that `lt_dlopen_ext ()' can
actually do the right thing even when not building shared libraries.
Guile doesn't currently use it, but the sketch of a solution is at:
http://thread.gmane.org/gmane.lisp.guile.devel/7897 .
Would you like to try this out?
>> I guess your linker supports shared libs but the `configure' somehow fails
>> to see it. Apparently Libtool's `_LT_LINKER_SHLIBS' M4 macro hasn't been
>> ported to your platform, leading to this incorrect diagnostic. Can you
>> report this to address@hidden
> The system doesnt support shared libraries at all.
Oh, it really doesn't? Then indeed, you'd need the `dlpreopen' trick
above.
Note that you can already use (or rather debug ;-)) Guile without
`dlpreopen'. You just won't be able to load modules that call
`load-extension'. In 1.8, it means you cannot use SRFI-1 and SRFI-60.
>> Hmm, this looks fishy as `string-ci<?' is a primitive procedure defined in
>> libguile.
> Can you suggest something?
I don't have any clue right now. I'd first look at the "freed cell"
issue, which means that the GC probably fails to scan part of the stack.
Hope this helps,
Ludo'.