libffi related bootstrap failure on sparc-sun-solaris2.8

libffi related bootstrap failure on sparc-sun-solaris2.8

[Gerald Pfeifer]

I had a successful bootstrap on sparc-sun-solaris2.8, but am (again)
seeing the following failure today:

  checking size of double... 8
  checking size of long double... 16
  checking size of void *... 8
  checking whether byte ordering is bigendian... cross-compiling... unknown
  checking to probe for byte ordering... guessing bigendian ...  unknown
  configure: error: unknown endianess - sorry
  gmake[1]: *** [configure-target-libffi] Error 1
  gmake[1]: Leaving directory `/files/pfeifer/OBJ-0402-1049'
  gmake: *** [bootstrap-lean] Error 2

The only changes that have been applied in the meantime are

  2002-04-01  Loren J. Rittle  <ljrittle@acm.org>

        * configure.in: Enable alpha*-*-freebsd*.
        * configure: Rebuilt.

  2002-03-30  Krister Walfridsson  <cato@df.lth.se>

        * configure.in: Enable i*86-*-netbsdelf*.
        * configure: Rebuilt.

  2002-03-29  David Billinghurst <David.Billinghurst@riotinto.com>

        PR other/2620
        * src/mips/n32.s: Delete
        * src/mips/o32.s: Delete

but I don't see how any of these three could actually have caused this.

(Krister's patch which was installed by Bryce, looks a bit larger, but
as far as I could see, this was just do to autoconf behaving very stupid
wrt line numbers.)

Gerald

Re: libffi related bootstrap failure on sparc-sun-solaris2.8

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

Gerald> I had a successful bootstrap on sparc-sun-solaris2.8, but am (again)
Gerald> seeing the following failure today:

I think I've seen other reports that 2.8 builds fine.
There's some email in my java folder from Brad Lucier implying that
this is the case.

Gerald>   checking whether byte ordering is bigendian... cross-compiling... unknown
Gerald>   checking to probe for byte ordering... guessing bigendian ...  unknown

I looked at the config.log snippet you sent.
This code from the test case fails:

    #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN
     bogus endian macros
    #endif

How are these macros defined on your system?
We look for them in sys/types.h and sys/param.h.
Maybe there is a fixincludes problem of some kind?

Failing that we can find a way to improve the configure macro in
question.

Tom

Re: libffi related bootstrap failure on sparc-sun-solaris2.8

[Gerald Pfeifer]

On 2 Apr 2002, Tom Tromey wrote:
>> I had a successful bootstrap on sparc-sun-solaris2.8, but am (again)
>> seeing the following failure today:
> I think I've seen other reports that 2.8 builds fine.

Mainline built fine a few hours ago; I'm running another mainline build
just right now and will then try the branch again.

> I looked at the config.log snippet you sent.
> This code from the test case fails:
>
>     #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN
>      bogus endian macros
>     #endif
>
> How are these macros defined on your system?
> We look for them in sys/types.h and sys/param.h.

These aren't defined in any of these two system files on our Solaris
8/SPARC boxes:

  % egrep 'BYTE_ORDER|BIG_ENDIAN|LITTLE_ENDIAN' /usr/include/sys/{types,param}.h
  /usr/include/sys/param.h:#ifdef _LITTLE_ENDIAN
  /usr/include/sys/param.h:#ifdef _BIG_ENDIAN

However, /usr/include/sys/isa_defs.h is #included by param.h and it has
  #define _BIG_ENDIAN
(Note the underscore!)

> Maybe there is a fixincludes problem of some kind?

sys/param.h and isa_defs.h are no fixincluded on sparc-sun-solaris2.8;
sys/types.h is, but the changes seem unrelated.

> Failing that we can find a way to improve the configure macro in
> question.

Anything I could try?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: libffi related bootstrap failure on sparc-sun-solaris2.8

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

Gerald> Mainline built fine a few hours ago; I'm running another
Gerald> mainline build just right now and will then try the branch
Gerald> again.

Do you mean it works on the main line and not the branch?
If so that's quite surprising.  The trunk and branch libffi/configure
scripts are identical.

Gerald> However, /usr/include/sys/isa_defs.h is #included by param.h
Gerald> and it has
Gerald>   #define _BIG_ENDIAN
Gerald> (Note the underscore!)

Ok.  This suggests that the test itself is buggy..

>> Failing that we can find a way to improve the configure macro in
>> question.

Gerald> Anything I could try?

I looked at the config.log output again.  Then I re-read the configury
code in libffi/aclocal.m4.  I see this at the very end of your
config.log posting:

    configure:3358: /files/pfeifer/OBJ-0322-22:00/gcc/xgcc -B/files/pfeifer/OBJ-0322-22:00/gcc/ -B/files/pfeifer/gcc/sparc-sun-solaris2.8/bin/ -B/files/pfeifer/gcc/sparc-sun-solaris2.8/lib/ -isystem /files/pfeifer/gcc/sparc-sun-solaris2.8/include -o conftest -g -O2   conftest.c  1>&5
    configure: failed program was:
    #line 3345 "configure"
    #include "confdefs.h"
    main () {
      /* Are we little or big endian?  From Harbison&Steele.  */
      union
      {
	long l;
	char c[sizeof (long)];
      } u;
      u.l = 1;
      exit (u.c[sizeof (long) - 1] == 1);
    }


Ok.  The test I quoted earlier was not the last one.  Reading more
closely, that test can fail in some situations without indicating a
bug.

I'm not certain why the above test failed in your situation.  It seems
like at least some error message should be printed.  But that's ok too
-- even that test can fail normally, since it is a run-test which
can't work when cross-compiling.

There is yet another test in that macro in aclocal.m4.  We need to
know why that one didn't get run.  That is the test we would expect to
find the answer.


I think there are a couple things you could do that would help.

First, if indeed this code works on the trunk and not the branch, look
at the differences between the two.  See how the config.log files
differ.

Next, it might help to add debugging code to libffi/configure and then
re-run the configury to see what actually happens.  I usually start by
finding the section of code I care about and then adding `set -x'/`set +x'
around it.

Tom

Re: libffi related bootstrap failure on sparc-sun-solaris2.8

[Gerald Pfeifer]

On 2 Apr 2002, Tom Tromey wrote:
> Do you mean it works on the main line and not the branch?
> If so that's quite surprising.  The trunk and branch libffi/configure
> scripts are identical.

I have it! The difference is not whether I'm testing trunk or branch,
the difference is whether the host is

  % isainfo -v
  64-bit sparcv9 applications
  32-bit sparc applications

which is okay, or

  % isainfo -v
  32-bit sparc applications

which is where this configure test breaks. (I didn't notice this before,
for the two boxes I've been using for many months are supposed to be
completely identical.)

> Ok.  This suggests that the test itself is buggy..

Indeed.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/