Re: Guile Build Errors

[ludo@gnu.org (Ludovic Courtès)]

Hi,

bornlibra23 <awarikoo@nse.co.in> 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 bug-libtool@gnu.org?
> 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'.