Bart De VOS pointed out that removing absolute paths from the libc linker scripts is plainly wrong.
It dates from dawn ages of the original crosstool code, and is not well explained. At that time, binutils might not understand the sysroot stuff, and it was necessary to remove absolute paths in that case.
/trunk/scripts/build/libc/glibc.sh | 14 2 12 0 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
1 Fix building gfortran for ARM.
2 http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01010.html
5 The patch below fixes a crash building libgfortran on arm-linux-gnueabi.
7 This target doesn't really have a 128-bit integer type, however it does use
8 TImode to represent the return value of certain special ABI defined library
9 functions. This results in type_for_size(TImode) being called.
11 Because TImode deosn't correspond to any gfortran integer kind
12 gfc_type_for_size returns NULL and we segfault shortly after.
14 The patch below fixes this by making gfc_type_for_size handle TImode in the
15 same way as the C frontend.
17 Tested on x86_64-linux and arm-linux-gnueabi.
22 2007-05-15 Paul Brook <paul@codesourcery.com>
25 * trans-types.c (gfc_type_for_size): Handle signed TImode.
27 diff -durN gcc-4.2.3.old/gcc/fortran/trans-types.c gcc-4.2.3/gcc/fortran/trans-types.c
28 --- gcc-4.2.3.old/gcc/fortran/trans-types.c 2007-08-31 10:27:50.000000000 +0200
29 +++ gcc-4.2.3/gcc/fortran/trans-types.c 2008-07-17 09:54:20.000000000 +0200
30 @@ -1799,6 +1799,13 @@
31 if (type && bits == TYPE_PRECISION (type))
35 + /* Handle TImode as a special case because it is used by some backends
36 + (eg. ARM) even though it is not available for normal use. */
37 +#if HOST_BITS_PER_WIDE_INT >= 64
38 + if (bits == TYPE_PRECISION (intTI_type_node))
39 + return intTI_type_node;