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 781765 - glibc 2.15 doesn't compile on ARM sfp/hfp platforms with gcc 4.7.0-0.5
Summary: glibc 2.15 doesn't compile on ARM sfp/hfp platforms with gcc 4.7.0-0.5
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: arm
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeff Law
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2012-01-14 22:46 UTC by Peter Robinson
Modified: 2016-11-24 16:16 UTC (History)
5 users (show)

Fixed In Version: glibc-2.15-4.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-25 09:38:23 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
patch from upstream commit 2d80bda39073a35af4b904d27fa1511cd309b26f (1.10 KB, patch)
2012-01-24 19:29 UTC, Mark Salter 		no flags Details | Diff
View All

Description Peter Robinson 2012-01-14 22:46:27 UTC 
glibc-2.14.1-2 built fine on ARM on both the hardfp and softfp platforms.

Trying to build glibc-2.15-2.fc17 fails with the following errors:

checking for forced unwind support... no
configure: error: forced unwind support is required

It seems that the configure flags in the spec file actually conflict (this is the case on mainline x86 too)

+ configure_CFLAGS=' -fasynchronous-unwind-tables -DNDEBUG -g -O3  -fno-asynchronous-unwind-tables'
+ ../configure CC=gcc CXX=g++ 'CFLAGS= -fasynchronous-unwind-tables -DNDEBUG -g -O3  -fno-asynchronous-unwind-tables' --prefix=/usr --enable-add-ons=../glibc-ports-2.15-8a70b2d,nptl,c_stubs,libidn --with-headers=/usr/include --enable-kernel=2.6.32 --enable-bind-now --build=armv7hl-redhat-linuxeabi --disable-profile --enable-nss-crypt

The full logs are here, it doesn't get beyond configure.

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=261506

This built fine on the previous gcc 4.6.2 / glibc 2.14 that we had on arm.

Not sure if this is a glibc change or an issue/change in gcc 4.7.0 RC
Comment 1 Peter Robinson 2012-01-14 23:18:18 UTC 
Reassigning to gcc as if we test compile glibc-2.15-2.fc17 with the gcc 4.6.1 we have in F-15 ARM it gets past the configure and begins building so it looks like a bug or change in gcc 4.7.0
Comment 2 Jakub Jelinek 2012-01-16 17:43:16 UTC 
I think:

--- a/gcc.spec
+++ b/gcc.spec
@@ -1912,6 +1912,14 @@ fi
 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spu2vmx.h
 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/vec_types.h
 %endif
+%ifarch %{arm}
+%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind-arm-common.h
+%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h
+%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/arm_neon.h
+%endif
+%ifarch sparc sparcv9 sparc64
+%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/visintrin.h
+%endif
 %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2
 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/crt*.o
 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgcc.a
@@ -2625,6 +2633,8 @@ fi
 %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/plugin
 
 %changelog
+- package up arm and sparc specific headers (#781765)
+
 * Thu Jan 12 2012 Jakub Jelinek <jakub> 4.7.0-0.6
 - update from trunk
   - PRs ada/41929, bootstrap/51705, bootstrap/51796, c++/47450,

(untested) should fix this up.  Will include it in gcc-4.7.0-0.7.fc17 later this week.
Comment 3 Jakub Jelinek 2012-01-18 15:49:23 UTC 
Should be fixed in gcc-4.7.0-0.7.fc17.
Comment 4 Peter Robinson 2012-01-18 16:22:56 UTC 
except your build failed on ARM.

http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=43485
Comment 5 Jakub Jelinek 2012-01-18 16:37:27 UTC 
That didn't look like my fault though, there is some libpng12 vs. libpng15 mess up in the buildroots.  There were no changes on the libjava side recently.
Comment 6 Brendan Conoboy 2012-01-18 19:52:57 UTC 
checking GTK_LIBS... -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpng12 -lm -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  

Looks like gcc is off the hook.  GTK_LIBS is bringing in the png12 dependency.
Comment 7 Jakub Jelinek 2012-01-19 08:44:25 UTC 
DEBUG util.py:257:    libpng.armv5tel 2:1.5.7-1.fc17
DEBUG util.py:257:    gtk2-devel.armv5tel 0:2.24.4-1.fc15
DEBUG util.py:257:    glib2-devel.armv5tel 0:2.28.8-1.fc15

I guess mixing FC15 gtk2/glib2 with FC17 libpng is a problem here, same issue is apparently on sparc (gcc also FTBFS there because of this).
Comment 8 Peter Robinson 2012-01-19 09:51:29 UTC 
> I guess mixing FC15 gtk2/glib2 with FC17 libpng is a problem here, same issue
> is apparently on sparc (gcc also FTBFS there because of this).

Yes, working to get a build in there now. There looks to be a problem with icu too (both x86 and ARM but different locations/problems). The ARM problem looks to be gcc based but possibly the same issue that should be fixed by this one.
Comment 9 Peter Robinson 2012-01-22 11:44:18 UTC 
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=270312

We got further but I'm not sure if the undefined reference is gcc or glibc

make -s subdir=malloc -C malloc ..=../ others
make[2]: Entering directory `/builddir/build/BUILD/glibc-2.15-a316c1f/malloc'
make[2]: Leaving directory `/builddir/build/BUILD/glibc-2.15-a316c1f/malloc'
make[2]: Entering directory `/builddir/build/BUILD/glibc-2.15-a316c1f/malloc'
/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/malloc/libmemusage_pic.a(memusage.os): In function `me':
/builddir/build/BUILD/glibc-2.15-a316c1f/malloc/memusage.c:258: undefined reference to `__aeabi_read_tp'
collect2: error: ld returned 1 exit status
make[2]: *** [/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/malloc/libmemusage.so] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/glibc-2.15-a316c1f/malloc'
make[1]: Leaving directory `/builddir/build/BUILD/glibc-2.15-a316c1f'
make[1]: *** [malloc/others] Error 2
Comment 10 Peter Robinson 2012-01-22 12:28:22 UTC 
That was with gcc-4.7.0-0.8.fc17 btw
Comment 11 Brendan Conoboy 2012-01-23 21:59:23 UTC 
This build failure is armv5tel specific.  I am able to reproduce this on armv5tel but not armv7hl.
Comment 12 Brendan Conoboy 2012-01-23 23:18:15 UTC 
The failing command line is:
gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.3  -B/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/csu/   -Wl,-soname=libmemusage.so -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both  -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/math -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/elf -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/dlfcn -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/nss -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/nis -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/rt -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/resolv -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/crypt -L/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/nptl -Wl,-rpath-link=/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/math:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/elf:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/dlfcn:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/nss:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/nis:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/rt:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/resolv:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/crypt:/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/nptl -o /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/malloc/libmemusage.so -T /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/shlib.lds /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/csu/abi-note.o -Wl,--whole-archive /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/malloc/libmemusage_pic.a -Wl,--no-whole-archive /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/elf/interp.os /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/dlfcn/libdl.so /builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/elf/ld.so 
/builddir/build/BUILD/glibc-2.15-a316c1f/build-armv5tel-redhat-linuxeabi/malloc/libmemusage_pic.a(memusage.os): In function `me':
Comment 13 Brendan Conoboy 2012-01-24 06:18:23 UTC 
This does not appear to be a gcc issue any longer.  Using gcc-4.7.0-0.8.fc17 my fc17 trimslice is able to build glibc-2.14.1-2.src.rpm on armv5tel as well as glibc-2.15-2.fc17.src.rpm on armv7hl.  The only build which does not succeed is glibc-2.15-2.fc17.src.rpm on armv5tel.  Since gcc 4.7 works on an earlier glibc of the same ABI and the current glibc with the v7 ABI, this is probably an issue with armv5tel support in the latest glibc.

Some notes from investigating the problem:

The __aeabi_read_tp function is defined in the various libc.a's during build time, but when linking libmemusage.so only libc.so is used.  In libc.so, __aeabi_read_tp is defined but not global:

00018160 t __aeabi_read_tp

This seems to be a red herring though- __aeabi_read_tp is likewise "t" with the glibc 2.14 build.  The only difference between glibc 2.14 and 2.15 is that when memusage.c is built on armv5tel, a call to getenv() results in __aeabi_read_tp being put into the assembly (only one call though- other calls to getenv() do not have this problem):

a portion of memusage.s on armv5tel:
.LVL24:
       cmp     r0, #0
       beq     .L11
       .loc 1 258 0 is_stmt 0 discriminator 1
       ldr     r3, .L34+72
       bl      __aeabi_read_tp @ load_tp_soft

On armv7hl the source is a different:
.LVL24:
       cmp     r0, #0
       beq     .L11
       .loc 1 258 0 is_stmt 0 discriminator 1
       ldr     r3, .L34+72
       mrc     p15, 0, r2, c13, c0, 3  @ load_tp_hard

This is the bit of C that causes the call to __aeabi_read_tp:

    outname = getenv ("MEMUSAGE_OUTPUT");

It's quite unremarkable as code goes, but removing the getenv call likewise removes the call to __aeabi_read_tp.  Strangely enough there are other calls to getenv in memusage.c, but this is the only mention of __aeabi_read_tp.

I'm not a glibc developer so I don't know what the right fix is.  Presumably aeabi_read_tp could be made global in libc.so, but perhaps using aeabi_read_tp at all is a bug?  Could use some glibc feedback here.
Comment 14 Brendan Conoboy 2012-01-24 06:39:48 UTC 
Minor update, that's line 258 (not 256), the last line of:

    outname = getenv ("MEMUSAGE_OUTPUT");
    if (outname != NULL && outname[0] != '\0'
       && (access (outname, R_OK | W_OK) == 0 || errno == ENOENT))

My test erroneously made outname NULL, causing the if() to never evaluate line 258 at all.  It is presumably the access() that results in __aeabi_read_tp since it's the only time it is called in the source file.
Comment 15 Brendan Conoboy 2012-01-24 18:12:46 UTC 
Nope, not access, it's errno.
Comment 16 Mark Salter 2012-01-24 19:29:15 UTC 
Created attachment 557296 [details]
patch from upstream commit 2d80bda39073a35af4b904d27fa1511cd309b26f
Comment 17 Jeff Law 2012-01-24 21:44:27 UTC 
I resync'd the glibc-ports code from the master sources which ought to fix this problem.
Comment 18 Peter Robinson 2012-01-25 09:38:23 UTC 
Confirmed built in arm on sfp/hfp. Thanks for your help.

http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=48517
Note You need to log in before you can comment on or make changes to this bug.