Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 708452
Summary: | glibc fails to build on ARMv5tel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> | ||||||||||
Component: | glibc | Assignee: | Andreas Schwab <schwab> | ||||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | rawhide | CC: | 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 13:12:04 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 245418 | ||||||||||||
Attachments: |
|
Description
Peter Robinson
2011-05-27 17:06:10 UTC
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
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
Created attachment 501348 [details]
F-14 patch for armv5tel
Patch needed for F-14.
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. The same issue is seen on ARMv7hl builds as well. 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. (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 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 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. (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. 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 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 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! 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 |