On Fri, Jul 3, 2009 at 10:33 PM, Jim Gifford<maillist@xxxxxxxxx> wrote:
In file included from /tools/include/endian.h:37,
from /tools/include/ctype.h:41,
from
/mnt/clfs/var/build_system/work/gcc-4.4.0/gcc/../include/safe-ctype.h:122,
from
/mnt/clfs/var/build_system/work/gcc-4.4.0/gcc/system.h:179,
from
/mnt/clfs/var/build_system/work/gcc-4.4.0/gcc/genmodes.c:22:
/tools/include/bits/endian.h:34:4: warning: #warning Cannot determine
current byte order, assuming big-endian.
I would expect the target should select an endianess. Is this a
bi-endian toolchain? This is a problem with your gcc build.
genmodes.c:(.text+0xc8b): undefined reference to `__nldbl_snprintf'
I believe this is also a problem with the way in which you build gcc,
it should not be referencing the old-abi where long double is equal to
double.
The first build of the new glibc is built with two sets of libm
symbols, the compat set for existing applications that used the
old-ABI where long double was the same as double, and a new set where
long double is distinct. When you rebuild gcc you must verify that you
are linking against the glibc you *just* built which should have the
correct old-ABI symbols.
You should review your use of --with-sysroot and --with-build-sysroot
when configuring the final gcc. For example I notice that you
conifgure the final gcc with "--with-sysroot=$(CLFS)" but I don't see
anywhere in the documentation that sets CLFS.
Additional information which might help if you submit another issue like this:
- Configure command-line with variables substitued.
- Configure config.log.
Cheers,
Carlos.
Just for reference my toolchain guy found the issue. It was related to
GCC. Here's the information and the fix. When gcc was configured it was told to find MPFR, GMP, PPL, and
CLooG-PPL in /tools. However, when compiling gcc uses these same values
for building native helper programs that run on the host. The following
sed will change those values to look in cross-tools for the native
programs only: