When I build mainline glibc for arm-none-eabi-linux-gnueabi, I get: .../default/csu/crti.S: Assembler messages: .../default/csu/crti.S:15: Error: undefined local label `.L10' .../default/csu/crti.S:17: Error: undefined local label `.L10' A patch to fix this is at: http://sourceware.org/ml/libc-alpha/2006-05/msg00017.html
The patch is to sysdeps/generic/initfini.c, and seems obvious. I could create an ARM-specific initfini.c to work around this, but is that really necessary?
There is no reason in general that function should not be inlined. It really should be inlined. Perhaps you can find a fix for the arm build that does not deoptimize the code.
Subject: Re: arm-none-eabi-linux-gnueabi doesn't build On Fri, May 19, 2006 at 07:22:53PM -0000, roland at gnu dot org wrote: > There is no reason in general that function should not be inlined. > It really should be inlined. Perhaps you can find a fix for the arm build that > does not deoptimize the code. Then I'll mark it non-inlined in an ARM copy; but I expect this to cause problems on many other targets. It only materializes on very recent versions of GCC, because previously we used -fno-unit-at-a-time which suppressed the "inline static functions called once" optimization; if GCC is new enough we use -fno-toplevel-reorder instead. Sedding GCC's assembly output has historically worked "well enough" for simple calls to known static functions, but it's not surprising that call_gmon_start requires a constant pool. I expect to see similar problems at least for SH. Anyway, you want an ARM-only fix, you'll get one :-) I'll take care of it.
Change was checked in earlier in the year: 2006-05-30 Daniel Jacobowitz <dan@codesourcery.com> * sysdeps/arm/initfini.c: New file.