Christophe Rhodes wrote:
> > Ignore tests which currently fail on mips. foreign.test.sh is the
> > odd one out, mips falls in the debugger, I haven't had a closer look
> > yet.
> ... tests which fail. I don't like this, because the tests lose their
> documenting and nagging nature in this case. On the other hand, if
> this is what is required for Peter's debian package, that's fine, and
> he can track mainline but with tests deactivated.
Since the tests stop at the first bad one, the alternative would be
to disable them completely for mips/mipsel. That's clearly worse than
disabling only some of them.
> > The stat-related test failures in contrib/posix are most likely
> > caused by a inconsistent structure definition which doesn't match
> > the one used by linux/mips. There's probably a way to automatically
> > extract it from /usr/include/bits/stat.h, but that's not done in the
> > current implementation.
> It is meant to be done: contrib/sb-posix/constants.lisp is processed
> by sb-grovel, emitting contrib/sb-posix/constants.lisp-tmp which is
> then processed as a lisp file. sb-grovel is meant to use the C
> compiler to grovel a machine-specific structure, and stat is one such
> that we ask for: see alien-stat in contrib/sb-posix/constants.lisp.
Ah, I see. sb-grovel misses -D_FILE_OFFSET_BITS=64, which is default
on mips linux. (The proper value for the glibc in use can be looked up
via `getconf LFS_CFLAGS`.)
> Is the status now that, apart from these failing tests, the mips/linux
> (and mipsel/linux) builds are expected to work?
I have done some tests on a slower machine, but no full rebuild there.
I don't see any breakage on a BCM91250A except for exhausted heap space
with the ansi tests.
I haven't tested mipsel yet, simply because the fastest machine I have
ATM is an old DECstation. :-)