The head built with debian i386 gcc 4 bombs with a stack overflow on
startup. Under gdb it looks like it really has used up its 80kbytes,
but I can't tell where or why. The same built with gcc 3.3 is ok, so
something evil has happened.
___
Guile-devel
goops.test fails under SCM_DEBUG=1,
(eval '(define-class ()
(x #:accessor x #:init-value 123)
(z #:accessor z #:init-value 789))
(current-module))
gives
Non-pair accessed with SCM_C[AD]R: `#< b7b08cf0>'
Dunno what it means, but
Ken Raeburn <[EMAIL PROTECTED]> writes:
>
> From the comments, it looks like the list returned by scm_i_dynwinds
> can have both cons cells and smob objects in it, like the winder
> object that was keeping the snarf step from working for me.
Yep that happens for me too, though it seems to have bee
Ken Raeburn <[EMAIL PROTECTED]> writes:
>
> The attached patch allows me to compile after configuring with
> CPPFLAGS=-DSCM_DEBUG.
Thanks, I applied that.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-deve
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>
> Shouldn't this be excercised by a test as well?
Maybe, but I don't see an easy way to do that in the normal svr4
linker case. If we had a static-only platform and were using libtool
-dlopen the way it's meant to be then I guess it'd bomb.
> I'm lo
Kevin Ryde wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
make check
isn't complaining.
I think it works only because that preload array is empty. There's a
Shouldn't this be excercised by a test as well?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Kevin Ryde wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
make check
isn't complaining.
I think it works only because that preload array is empty. There's a
terminating zero entry, so the fetch from there gives NULL, and
lt_dlpreload_default can tolerate NULL (it looks like NULL is w
