I see this:
* control.in/main, sysdeps/amd64.mk, sysdeps/i386.mk,
sysdeps/kfreebsd-amd64.mk, sysdeps/kfreebsd-i386.mk, sysdeps/sparc.mk : use
gcc-4.3 on amd64, i386, kfreebsd-i386, kfreebsd-amd64 and sparc.
* sysdeps/i386.mk, sysdeps/kfreebsd-i386.mk: use default gcc optimizations
on i386 and kfreebsd-i386 (-march=i486 -mtune=generic).
i.e., they are changing the compiler and optimizations. That means
that potentially a whole lot of things are compiled differently.
You'd like to hope that it would make no difference, but there may be
something subtle there.
On 03 Mar 2008 00:23:20 +0200, Juho Snellman <jsnell@...> wrote:
> Rupert Swarbrick <rswarbrick@...> writes:
> > I guess if nothing else, it might help us work out which of the patches
> > to glibc broke things and why.
> Assuming the debian changelog is complete, it's hard to see any really
> good candidates for a patch that would have broken things in the range
> of 2.7-7 to 2.7-9. Most of it is completely unrelated to anything
> that is of interest to SBCL (updates to translations, manuals, to code
> on weird platforms, etc):
> The only even borderline suspicious looking one is
> patches/sh4/cvs-nptl-private-futexes.diff (if futexes are unreliable,
> random hangs would make a lot of sense). Except that I thought that we
> didn't really use anything provided by glibc to use futexes, but just
> directly used the syscall, so they should be unable to break it for
> One easy way to test this theory would be to build sbcl without
> threading support, but use the new glibc. If it still hangs, it's not
> threading related. (If it doesn't hang, it could still be something
> else, but the pickings in that changelog are very slim).
> Juho Snellman