Bug 708452

Summary: glibc fails to build on ARMv5tel
Product: [Fedora] Fedora Reporter: Peter Robinson <pbrobinson>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dennis, fweimer, jakub, jcm, kad, ndevos, nickc, schwab
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glibc-2.14.90-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-11 09:12:04 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418    
Attachments:
Description Flags
Patch used for glibc build in F-13 glibc-2.12
none
patch to F-16/F-15 spec file for arm5
none
F-14 patch for armv5tel
none
patch for tzdata-update.c to include support for ARM none

Description Peter Robinson 2011-05-27 13:06:10 EDT
In Fedora 13 with glibc 2.12 on arm we needed to apply a patch and make some changes to the spec so it will build (will attach).

With glibc 2.13 and 2.13.90 in Fedora 14/15/rawhide even with the patches applied it still fails to build.

The scratch build logs for 2.13 is available here:
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=94866

The scratch build logs for 2.13.90 is available here:
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=94872

The main error is:

make[2]: Entering directory `/builddir/build/BUILD/glibc-2.13/resolv'
gethnamaddr.c: In function 'getanswer':
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:282:19: warning: called from here
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:314:19: warning: called from here
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:365:19: warning: called from here
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:444:19: warning: called from here
gethnamaddr.c: In function '_gethtent':
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:814:17: warning: called from here
gethnamaddr.c: In function '_gethtent':
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:814:17: warning: called from here
gethnamaddr.c: In function 'getanswer':
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:282:19: warning: called from here
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:314:19: warning: called from here
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:365:19: warning: called from here
../include/netdb.h:18:1: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow
gethnamaddr.c:444:19: warning: called from here
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/libgcc_eh.a(unwind-arm.o): In function `__gnu_Unwind_Backtrace':
(.text+0xf28): undefined reference to `__stack_chk_guard'
collect2: ld returned 1 exit status
make[2]: *** [/builddir/build/BUILD/glibc-2.13/build-armv5tel-linuxnptl/resolv/libanl.so] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/glibc-2.13/resolv'
make[1]: *** [resolv/others] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/glibc-2.13'
RPM build errors:
Comment 1 Peter Robinson 2011-05-27 13:07:29 EDT
Created attachment 501346 [details]
Patch used for glibc build in F-13 glibc-2.12

Patch used for glibc build in F-13 glibc-2.12 to build on armv5tel platforms
Comment 2 Peter Robinson 2011-05-27 13:08:23 EDT
Created attachment 501347 [details]
patch to F-16/F-15 spec file for arm5

Patch to F-16/F-15 spec file for armv5tel builds
Comment 3 Peter Robinson 2011-05-27 13:08:58 EDT
Created attachment 501348 [details]
F-14 patch for armv5tel

Patch needed for F-14.
Comment 4 Peter Robinson 2011-05-27 13:10:26 EDT
It would be useful to get the glibc patch upstream in some form or another so ARMv5tel on Fedora doesn't need a special patch to build.

A patch to fix the build of gethnamaddr.c on F-14/F-15/F16 is needed as well.
Comment 5 Peter Robinson 2011-05-27 13:12:08 EDT
The same issue is seen on ARMv7hl builds as well.
Comment 6 Alexander Kanevskiy 2011-05-31 07:35:35 EDT
According to Linaro branch of gcc, adding "-fno-stack-protector" to LIBGCC2_CFLAGS and CRTSTUFF_CFLAGS would be more correct solution than patching glibc, as this unreferrenced symbol comes from libgcc.
Comment 7 Peter Robinson 2011-05-31 09:07:19 EDT
(In reply to comment #6)
> According to Linaro branch of gcc, adding "-fno-stack-protector" to
> LIBGCC2_CFLAGS and CRTSTUFF_CFLAGS would be more correct solution than patching
> glibc, as this unreferrenced symbol comes from libgcc.

We already add the following excerpt to the spec file for building. It sthat the same or different?

#no-asynchronous-unwind needed for .init/.fini check to pass
#no-stack-protector needed for _itoa double declaration
%ifarch %{arm}
BuildFlags="$BuildFlags -fno-asynchronous-unwind-tables -fno-stack-protector"
%else
BuildFlags="$BuildFlags -fasynchronous-unwind-tables"
%endif
Comment 8 Alexander Kanevskiy 2011-05-31 09:56:10 EDT
If you're getting error from above (undefined reference to `__stack_chk_guard') then this %ifarch is not effective and gets overruled somewhere in makefiles.

In MeeGo we had similar issue. Got solved by that: 

http://build.meego.com/package/view_file?file=gcc45-ARM-libgcc-no-stack-protector.patch&package=gcc&project=devel%3Abase&srcmd5=4f4a81abc813108469481ede578907c8
Comment 9 Jakub Jelinek 2011-05-31 10:10:45 EDT
If you need
%ifarch %{arm}
BuildFlags="$BuildFlags -fno-asynchronous-unwind-tables -fno-stack-protector"
%else
BuildFlags="$BuildFlags -fasynchronous-unwind-tables"
%endif
you are doing something seriously wrong.  You might need to override a compiler flag or two for a few source files, but that is supposed to be done through
*/sysdeps/*/arm/Makefile, not a broken hack like that.  glibc really should have unwind info correct at every single instruction if at all possible.

A patch like https://bugzilla.redhat.com/attachment.cgi?id=501346&action=diff
might be reasonable if it works (I doubt that given the
 struct startup_info
-{
+{f

hunk).  glibc_post_upgrade and tzdata-update ideally should be rewritten in <lua> if possible (just rewrote libgcc_post_upgrade that way last week), but if it isn't possible, you have the option either to hack it around for arm until it works, or give up and link it as a -static bloated executable for arm using normal library calls.  The reason for the special hacks is just to make the binary smaller.
Comment 10 Peter Robinson 2011-05-31 10:31:43 EDT
(In reply to comment #9)
> If you need
> %ifarch %{arm}
> BuildFlags="$BuildFlags -fno-asynchronous-unwind-tables -fno-stack-protector"
> %else
> BuildFlags="$BuildFlags -fasynchronous-unwind-tables"
> %endif
> you are doing something seriously wrong.  You might need to override a compiler
> flag or two for a few source files, but that is supposed to be done through
> */sysdeps/*/arm/Makefile, not a broken hack like that.  glibc really should
> have unwind info correct at every single instruction if at all possible.

Quite likely doing something seriously wrong. I'm not a C library expert, hence filing this bug with the hope of getting an expert like yourself to look at it and put a proper fix in place.

> A patch like https://bugzilla.redhat.com/attachment.cgi?id=501346&action=diff
> might be reasonable if it works (I doubt that given the
>  struct startup_info
> -{
> +{f
> 
> hunk).  glibc_post_upgrade and tzdata-update ideally should be rewritten in
> <lua> if possible (just rewrote libgcc_post_upgrade that way last week), but if
> it isn't possible

I personally have no idea if its possible. This was hack put in place on glibc 2.12 on F-13 to get it working. It works in that it runs on a number of ARM devices. I would personally prefer a proper upstream fix was put in place by someone that knows what "proper" is so all help is appreciated.

The arm koji build system is available for testing using arm-koji instead of koji with all the usual commands and options.
Comment 11 Niels de Vos 2011-06-06 17:32:42 EDT
Rewriting glibc_post_upgrade and tzdata-update in a <lua> scriptlet does not seem to be trivial, or at least not for me.

I guess that static-linking glibc_post_upgrade and tzdata-update is the easiest for now. The binaries will be bigger, but I guess a working glibc package is more useful at the moment. When/if the lua-scriptlets arrive, arm will profit from this hugely.

Until <lua> scriptlets are available, the patch for tzdata-update.c will be needed (and it still works unchanged).


Due to some issue (with gcc?), the following error causes the build failure:

/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/libgcc_eh.a(unwind-arm.o): In
function `__gnu_Unwind_Backtrace':
(.text+0xf28): undefined reference to `__stack_chk_guard'
collect2: ld returned 1 exit status


I'm unable to find where __stack_chk_guard is defined and what library should be used for linking. From my understanding glibc itself provides __stack_chk_guard. Therefore I'm preventing the -static-libgcc option from being passed on to gcc (with a very ugly hack which surely needs to be reviewed).

All changes are available in an srpm for testing:
- http://repos.fedorapeople.org/repos/devos/arm-fixes/fedora-13/SRPMS/glibc-2.13-2.0.bz708452.src.rpm

I've fired a scratch-build up in the hope it builds in arm-koji against dist-f13:
- https://arm.koji.fedoraproject.org/koji/taskinfo?taskID=96722
Comment 12 Nick Clifton 2011-06-07 11:46:31 EDT
Hi Peter,

  Looking at your original posting in the bug report:

...: warning: inlining failed in call to '__set_h_errno': call is unlikely and code size would grow

  All of these warnings can be safely ignored.

libgcc_eh.a(unwind-arm.o): In function `__gnu_Unwind_Backtrace':
(.text+0xf28): undefined reference to `__stack_chk_guard'

  This is the only real error.  I see in the F-13 glibc patch that you posted there is an attempt to fix this problem:

+++ ./fedora/tzdata-update.c	2010-11-05 21:04:22.000000000 -0400
[snip]
@@ -563,6 +592,12 @@ void __libc_csu_fini (void) { }
 pid_t __fork (void) { return -1; }
 char thr_buf[65536];
 
+#if defined __arm__
+/* Prevent pulling in libc-start.o (which also defines
+ * __libc_start_main.)  */
+unsigned int __stack_chk_guard = ~0U;
+#endif

  Given that you say that this patch has been applied, I am forced to assume that either tzdata-update.o is not being included in the link of libanl.so.  Maybe you could check to see why tzdata-update.o is not included ?

Cheers
  Nick
Comment 13 Niels de Vos 2011-06-07 13:37:53 EDT
Hi Nick,

The __stack_chk_guard error was happening when linking libBrokenLocale.so. this was the first .so that was linked. There .so do not need to be linked against libgcc (I think and hope).

tzdata-update should be static, so the patch is required.

Thanks for reviewing!
Comment 14 Niels de Vos 2011-06-10 09:25:35 EDT
Created attachment 504116 [details]
patch for tzdata-update.c to include support for ARM

This patch (glibc-arm-tzdata-update.patch) has been tested and replaces the one with the weird hunk. glibc-2.13/fedora/tzdata-update.c from glibc-2.13-fedora.tar.xz can be compiled the same way as on other architectures when this patch has been applied.

Is it possible to have this patch included in the upstream version of glibc-2.13-fedora.tar.xz? A reference build that shows that the patch does not interfere with building on x86_64 and i686 can be found here:
- http://koji.fedoraproject.org/koji/taskinfo?taskID=3122987