Guile Build Errors

Guile Build Errors

[bornlibra23]

Hello People
I am trying to compile guile-1.8.7 on Stratus Open VOS.
I am able to build it successfully but the following errors while testing
have left me perplexed. I am totally new to guile. Please suggest.
PASS: test-system-cmds
ERROR: In procedure dynamic-link:
ERROR: file: "libguile-srfi-srfi-1-v-3", message: "file not found"
FAIL: test-require-extension
ERROR: In procedure string-append:
ERROR: Wrong type (expecting string): #<freed cell 400876c0; GC missed a
reference>
FAIL: test-bad-identifiers
PASS: test-num2integral.pm
PASS: test-round.pm
PASS: test-gh.pm
ERROR: In procedure dynamic-link:
ERROR: file: "libtest-asmobs", message: "file not found"
FAIL: test-asmobs
PASS: test-list.pm
PASS: test-unwind.pm
fail: scm_is_signed_integer ((expt 2 63), -9223372036854775808,
9223372036854775807) == 0
FAIL: test-conversion.pm
FAIL: test-fast-slot-ref
Backtrace:
In unknown file:
    ...
   ?:  7  (begin (if # #) (make-modules-in # full-name))
   ?:  8* (if (or # #) (try-load-module name))
   ?:  9  [try-load-module (srfi srfi-1)]
   ?: 10  (or (begin (try-module-linked name)) (try-module-autoload name)
...)
   ?: 11* [try-module-autoload (srfi srfi-1)]
   ?: 12  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and #
#))
    ...
   ?: 13  (letrec ((load-file #)) (dynamic-wind (lambda () #) (lambda () #)
...) ...)
   ?: 14* [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f
()>]
   ?: 15* [#<procedure #f ()>]
   ?: 16* (let* ((file #)) (cond (# => #) (# => #)))
   ?: 17  [#<procedure #f #> "/<<PATH>>/guile-1.8.7/srfi/srfi-1.scm"]
    ...
   ?: 18  [with-fluid* #<fluid 7> #f #<procedure #f ()>]
   ?: 19* [#<procedure #f ()>]
   ?: 20* [load-file #<primitive-procedure primitive-load> ...]
   ?: 21* [save-module-excursion #<procedure #f ()>]
   ?: 22  (let (# #) (dynamic-wind # thunk #))
   ?: 23  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f
()>]
   ?: 24* [#<procedure #f ()>]
   ?: 25* [primitive-load "/<<PATH>>/guile-1.8.7/srfi/srfi-1.scm"]
In /<<PATH>>/guile-1.8.7/srfi/srfi-1.scm:
 223: 26* [load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"]

/<<PATH>>/guile-1.8.7/srfi/srfi-1.scm:223:1: In procedure dynamic-link in
expression (load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"):
/<<PATH>>/guile-1.8.7/srfi/srfi-1.scm:223:1: file:
"libguile-srfi-srfi-1-v-3", message: "file not found"
guile --use-srfi=1,10 fails to run
FAIL: test-use-srfi
PASS: test-scm-c-read.pm
PASS: test-scm-take-locale-symbol.pm
PASS: test-with-guile-module.pm
PASS: test-scm-with-guile.pm
==================================
6 of 16 tests failed
Please report to bug-guile@gnu.org
==================================
-- 
View this message in context: http://www.nabble.com/Guile-Build-Errors-tp25167250p25167250.html
Sent from the Gnu - Guile - User mailing list archive at Nabble.com.

Re: Guile Build Errors

[Ludovic Courtès]

Hello,

bornlibra23 <awarikoo@nse.co.in> writes:

> I am trying to compile guile-1.8.7 on Stratus Open VOS.

Woow, I had never seen this one, thanks for trying out.  ;-)

Can you post the GNU triplet as returned by `./build-aux/config.guess'?

> I am able to build it successfully but the following errors while testing
> have left me perplexed. I am totally new to guile. Please suggest.
> PASS: test-system-cmds
> ERROR: In procedure dynamic-link:
> ERROR: file: "libguile-srfi-srfi-1-v-3", message: "file not found"

Can you show the output of
"grep -A2 -E '(libtool supports|shared lib)' config.log" (assuming
GNU grep here)?

It may be that Libtool decided not to build shared libraries, in which
case module loading may not work.

> ERROR: In procedure string-append:
> ERROR: Wrong type (expecting string): #<freed cell 400876c0; GC missed a
> reference>
> FAIL: test-bad-identifiers

It shows that there's something wrong GC-wise.  It could be that the
stack is not correctly scanned on this platform.

Could you try to reproduce the problem with a simple test case, e.g., by
running `./pre-inst-guile' and trying

  (begin
    (string-append (make-string 123) (make-string 123))
    (gc))

and variants thereof to try to trigger the problem?

You may want to look at `libguile/gc_os_dep.c' to see how it determines
the stack and whether it makes sense?

You might need to add a new series of #ifdefs, possibly borrowed from
upstream libgc
(http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/os_dep.c?revision=1.42&view=markup).

> ==================================
> 6 of 16 tests failed
> Please report to bug-guile@gnu.org
> ==================================

Can you also try `./check-guile' and report back?

Thanks,
Ludo'.

Re: Guile Build Errors

[bornlibra23]

Hello Ludo'
I am new to the opensource world & coundnt understand some of your more
cryptic directions. I couldnt get the head or tail of the os deppendency
file. Perhaps you could ask me some questions like wether stack grows from
top or bottom & like to make me understand what the file requires.

>Woow, I had never seen this one, thanks for trying out.  ;-)
Its nice to do new things.

>Can you post the GNU triplet as returned by `./build-aux/config.guess'?
bash-2.05$ ./build-aux/config.guess
i786-stratus-vos

>Can you show the output of "grep -A2 -E '(libtool supports|shared lib)'
config.log" (assuming GNU grep here)?
bash-2.05$ grep -A2 -E '(libtool supports|shared lib)' config.log
configure:9171: checking whether the
/users/awarikoo/OpenSource/guile-1.8.7/buil
+d-aux/compile gcc linker (/system/gnu_library/bin/ld) supports shared
libraries
configure:10245: result: no
configure:10484: checking dynamic linker characteristics
--
configure:12167: checking if libtool supports shared libraries
configure:12169: result: no
configure:12172: checking whether to build shared libraries
configure:12193: result: no
configure:12196: checking whether to build static libraries
--
configure:28594: checking for shared library run path origin
configure:28607: result: done
configure:29108: checking for CFPreferencesCopyAppValue

>It shows that there's something wrong GC-wise.  It could be that the stack
is not correctly scanned on this platform.
>Could you try to reproduce the problem with a simple test case, e.g., by
running `./pre-inst-guile' and trying
>  (begin
>    (string-append (make-string 123) (make-string 123))
>    (gc))
>and variants thereof to try to trigger the problem?
bash-2.05$ ./pre-inst-guile
Backtrace:
In unknown file:
   ?: 47  (let (# #) (dynamic-wind # thunk #))
   ?: 48  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f
()>]
   ?: 49* [#<procedure #f ()>]
   ?: 50* [primitive-load
"/users/awarikoo/OpenSource/guile-1.8.7/ice-9/safe-r5rs.scm"]
In /users/awarikoo/OpenSource/guile-1.8.7/ice-9/safe-r5rs.scm:
  20: 51* (define-module (ice-9 safe-r5rs) :re-export ...)
  20: 52  (eval-case (# #) (else #))
In unknown file:
    ...
   ?: 53  (let* ((m (process-define-module #))) (set-current-module m) m)
   ?: 54* [process-define-module (# # # # ...)]
   ?: 55  (let* (# # # #) (beautify-user-module! module) (# kws # # ...)
...)
   ?: 56* [loop (#:re-export (eqv? eq? equal? ...) #:export ...) () ...]
   ?: 57  (if (null? kws) (call-with-deferred-observers (lambda () # ...))
...)
    ...
   ?: 58  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f
()>]
   ?: 59* [#<procedure #f ()>]
   ?: 60* [module-re-export! #<directory # 400abd50> (eqv? eq? equal?
number? ...)]
   ?: 61  (let* ((public-i #)) (for-each (lambda # #) names))
   ?: 62  [for-each #<procedure #f (name)> (eqv? eq? equal? ...)]
   ?: 63* [#<procedure #f (name)> string-ci<?]
   ?: 64* (let* ((var #)) (cond (# #) (# #) (else #)))
   ?: 65  (cond (# #) (# #) (else #))
    ...
   ?: 66  [scm-error misc-error #f "~A ~S" ("Undefined variable:"
string-ci<?) #f]

<unnamed port>: In procedure scm-error in expression (scm-error (quote
misc-error) #f ...):
<unnamed port>: Undefined variable: string-ci<?
bash-2.05$ (begin (string-append (make-string 123) (make-string 123)) (gc))
bash: syntax error near unexpected token `(string-append'

>You may want to look at `libguile/gc_os_dep.c' to see how it determines the
stack and whether it makes sense?
>You might need to add a new series of #ifdefs, possibly borrowed from
upstream libgc
>(http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/os_dep.c?revision=1.42&view=markup).
I will have a look at that after I get more understanding about the
compilation issues

>Can you also try `./check-guile' and report back?

bash-2.05$ ./check-guile
Testing /users/awarikoo/OpenSource/guile-1.8.7/pre-inst-guile ...
with GUILE_LOAD_PATH=/users/awarikoo/OpenSource/guile-1.8.7/test-suite
ERROR: In procedure symbol->string:
ERROR: Wrong type argument in position 1 (expecting symbol): #<freed cell
40087fd0; GC missed a reference>

Thanks
bornlibra23
-- 
View this message in context: http://www.nabble.com/Guile-Build-Errors-tp25167250p25236356.html
Sent from the Gnu - Guile - User mailing list archive at Nabble.com.

Re: Guile Build Errors

[Ludovic Courtès]

Hello,

bornlibra23 <awarikoo@nse.co.in> writes:

>>Can you post the GNU triplet as returned by `./build-aux/config.guess'?
> bash-2.05$ ./build-aux/config.guess
> i786-stratus-vos

I've never seen that.

> +d-aux/compile gcc linker (/system/gnu_library/bin/ld) supports shared
> libraries
> configure:10245: result: no

[...]

> configure:12172: checking whether to build shared libraries
> configure:12193: result: no

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).

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?

In the meantime, can you try "./configure --with-gnu-ld" and report the
output of `grep' similarly?

> <unnamed port>: In procedure scm-error in expression (scm-error (quote
> misc-error) #f ...):
> <unnamed port>: Undefined variable: string-ci<?

Hmm, this looks fishy as `string-ci<?' is a primitive procedure defined
in libguile.

> bash-2.05$ ./check-guile
> Testing /users/awarikoo/OpenSource/guile-1.8.7/pre-inst-guile ...
> with GUILE_LOAD_PATH=/users/awarikoo/OpenSource/guile-1.8.7/test-suite
> ERROR: In procedure symbol->string:
> ERROR: Wrong type argument in position 1 (expecting symbol): #<freed cell
> 40087fd0; GC missed a reference>

OK, so it barfs very early.

I don't have access to an "i786" machine, so I'm afraid I won't be able
to help much.

Thanks,
Ludo'.

Re: Guile Build Errors

[bornlibra23]

Hello Ludo'
> 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?

> 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.

> Hmm, this looks fishy as `string-ci<?' is a primitive procedure defined in
> libguile.
Can you suggest something?

Thanks
bornlibra23
-- 
View this message in context: http://www.nabble.com/Guile-Build-Errors-tp25167250p25254370.html
Sent from the Gnu - Guile - User mailing list archive at Nabble.com.

Re: Guile Build Errors

[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'.

Re: Guile Build Errors

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> 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.

What about statically linking all of the necessary libraries, and adding
a scm_c_register_extension () call to the application startup code for
each (load-extension ...) call that you expect Scheme code to make?
Wouldn't that work?

     Neil

Re: Guile Build Errors

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> 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.
>
> What about statically linking all of the necessary libraries, and adding
> a scm_c_register_extension () call to the application startup code for
> each (load-extension ...) call that you expect Scheme code to make?
> Wouldn't that work?

Yes, that should work, but it’s a bit of kludge in the sense that the
application shouldn’t have to know about all this.

Thanks,
Ludo’.