Arm cross gcc-3.4.0, glibc-2.3.2, binutils-1.1[45] build failure.

[Dimitry Andric]

On 2004-05-21 at 17:28:20 Jonathan Marks wrote:

> Here's the reported failure.
--snip--
> /usr/src/xscale/glibc-2.3.2-bld/csu/crti.S: Assembler messages:
> /usr/src/xscale/glibc-2.3.2-bld/csu/crti.S:96: Error: can't
> resolve `_GLOBAL_OFFSET_TABLE_' {*UND* section} - `.L7' {.text
> section}
> /usr/src/xscale/glibc-2.3.2-bld/csu/crti.S:61: Error:
> internal_relocation (type: OFFSET_IMM) not fixed up
> /usr/src/xscale/glibc-2.3.2-bld/csu/crti.S:62: Error:
> internal_relocation (type: OFFSET_IMM) not fixed up
> /usr/src/xscale/glibc-2.3.2-bld/csu/crti.S:63: Error:
> internal_relocation (type: OFFSET_IMM) not fixed up
> /usr/src/xscale/glibc-2.3.2-bld/csu/crti.S:64: Error:
> internal_relocation (type: OFFSET_IMM) not fixed up
--snip--
> Below is a copy of initfini.s  It looks like the compiler did not
> do too good a job of generating it.
> The gcc-3.3.2 compiler did a much better job.  Note how _BEGIN's and _END's are mixed up -
> eg. PROLOG_BEGIN with EPILOG_END.

Sorry to post a reply to this thread so late, but I think I found out
what causes this problem: using gcc 3.4.0 to compile initfini.c with
-O2 (which is the default optimization for glibc) !

I found this post from Oct 2003, titled "danger: current GCC makes a
hash out of initfini.c":

  http://sources.redhat.com/ml/libc-alpha/2003-10/msg00007.html

Roland McGrath (AFAIK one of the glibc developers) then answers:

"The initfini.c plan has always been fragile by its nature.  If it
works, it works.  If forcing -O1 for the file helps, there's no reason
not to do that."

So that's what I tried, and indeed, compiling with -O1 gives me a
non-mangled initfini.s file, which allows the rest of the glibc build
to continue.  Patches to achieve this are located here:

http://www.andric.com/cross/patches/glibc-2.3.2-initfini.patch.bz2
http://www.andric.com/cross/patches/glibc-linuxthreads-2.3.2-initfini.patch.bz2

This also offers an explanation for the fact that some people, in
particular the crosstool users, don't get this error, because
crosstool explicitly compiles glibc for arm with -O, see TARGET_CFLAGS
in arm*.dat.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 183 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/crossgcc/attachments/20040625/0ed5b713/attachment.sig>