[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)

From: Neil Jerram
Subject: Fwd: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)
Date: Sat, 31 May 2008 17:18:07 +0100

[Forwarding this to guile-devel, without the 13M attachment.]

---------- Forwarded message ----------
From: Neil Jerram <address@hidden>
Date: 2008/5/31
Subject: Re: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)
To: Thiemo Seufer <address@hidden>
Cc: address@hidden, guile-devel <address@hidden>

2008/5/29 Thiemo Seufer <address@hidden>:
> Neil Jerram wrote:
>> 2008/5/28 Thiemo Seufer <address@hidden>:
>> >
>> > After a closer look I believe the logic of the test is just plain wrong:
>> >
>> > aux (l) unsigned long l;
>> > { int x; exit (l >= ((unsigned long)&x)); }
>> > main () { int q; aux((unsigned long)&q); },
>> >
>> > The test returns true for a downward-growing stack, but that sets
>> Are you sure you're not missing a step?  According to my
>> understanding, for a downwards-growing stack:
>>    &x < l
>>    => (l >= &x) is TRUE
>>    => exit status of the test program is non-zero
> This is what I saw when running the test manually.
>>    => AC_TRY_RUN believes that the test program _failed_
>>    => SCM_I_GSC_STACK_GROWS_UP stays as 0
> However, config.log shows SCM_I_GSC_STACK_GROWS_UP=1, and that's also
> the value used further down the build. Unfortunately the check doesn't
> print a message to that effect, so we can't cross-check with other
> build logs. (I only ran guile builds on mips.)
>> > For paranoia reasons I checked that
>> > the test behaves the same on mips, powerpc and i386.
>> What exactly do you mean here?  (My guess: that you compiled and ran
>> the test program by hand, and that the exit status was 1 in each
>> case?)
> Yes, that's what I meant.

Thanks.  So, do you agree that my interpretation of what _should_
happen is correct, and that we are therefore looking for a bug
somewhere that can cause a non-zero exit status to map to


- The compiler.  Is it possible that your compiler doesn't map the arg
of exit(...) to the exit status that the shell sees?

- ./configure code.  Is there a bug in the ./configure code that
confuses the exit status on some platforms only?  Are you still using
the ./configure that came with Guile 1.8.5, or have you regenerated
it?  If the latter, the bug could be being introduced by different
versions of the autotools than the ones we used upstream.

I wish I could reproduce this myself, so I could investigate in
detail!  I've downloaded the Debian package source (for
guile-1.8-1.8.5+1), and built it on an ia64 machine, and I don't see
the problem.  I've attached my ./configure - can you check that it is
the same as the one in the official Debian build (in case I've made a
mistake with the patching process)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]