Re: 64bits & df

["David S. Miller" <davem@redhat.com>]

Ok, found the sparc64 glibc relocation problem.

sysdeps/sparc/sparc64/elf/configure.in has a test for broken
relocation handling, it looks like this:

# Check for broken WDISP22 in the linker.
AC_CACHE_CHECK(for sparc64 ld WDISP22 handling, libc_cv_sparc64_wdisp22, [dnl
echo 'bne foo; nop' > conftest1.s
echo '.globl foo; .hidden foo; foo: nop' > conftest2.s
libc_cv_sparc64_wdisp22=unknown
if AC_TRY_COMMAND(${CC-cc} -nostdlib -shared $CFLAGS conftest1.s conftest2.s -o conftest.so 1>&AS_MESSAGE_LOG_FD); then
  if readelf -r conftest.so | grep -q R_SPARC_WDISP22; then
    libc_cv_sparc64_wdisp22=broken
  else
    libc_cv_sparc64_wdisp22=ok
  fi
fi
rm -f conftest*])
if test $libc_cv_sparc64_wdisp22 != ok; then
  AC_DEFINE(BROKEN_SPARC_WDISP22)
fi

For some reason this test passes and the sparc64 glibc build thinks
BROKEN_SPARC_WDISP22 does not need to be defined.  However, we end
up with one of these bogus relocations when building the shared version
of "linuxthreads/sysdeps/unix/sysv/sparc/sparc64/vfork.S".

A quick workaround, until the true cause is discovered, would be to
force BROKEN_SPARC_WDISP22 for the Debian sparc64 glibc builds.

When I run this testcase by hand, .... wait, that's the problem likely.
It uses "gcc-3.3" as CC which doesn't have all of the "uname -m" output logic
the /usr/bin/gcc script written by Ben has.  If the configure test above
is run without an explicit "-m64" it will create a 32-bit shared object
for the test case.  On sparc32 the test does pass properly, on sparc64
it does not.