This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 781765 - glibc 2.15 doesn't compile on ARM sfp/hfp platforms with gcc 4.7.0-0.5
glibc 2.15 doesn't compile on ARM sfp/hfp platforms with gcc 4.7.0-0.5
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
arm Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2012-01-14 17:46 EST by Peter Robinson
Modified: 2012-01-25 04:38 EST (History)
4 users (show)

See Also:
Fixed In Version: glibc-2.15-4.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-25 04:38:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Peter Robinson 2012-01-14 17:46:27 EST
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 18:18:18 EST
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 12:43:16 EST
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@redhat.com> 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 10:49:23 EST
Should be fixed in gcc-4.7.0-0.7.fc17.
Comment 4 Peter Robinson 2012-01-18 11:22:56 EST
except your build failed on ARM.

http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=43485
Comment 5 Jakub Jelinek 2012-01-18 11:37:27 EST
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 14:52:57 EST
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 03:44:25 EST
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 04:51:29 EST
> 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 06:44:18 EST
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 07:28:22 EST
That was with gcc-4.7.0-0.8.fc17 btw
Comment 11 Brendan Conoboy 2012-01-23 16:59:23 EST
This build failure is armv5tel specific.  I am able to reproduce this on armv5tel but not armv7hl.
Comment 12 Brendan Conoboy 2012-01-23 18:18:15 EST
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 01:18:23 EST
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 01:39:48 EST
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 13:12:46 EST
Nope, not access, it's errno.
Comment 16 Mark Salter 2012-01-24 14:29:15 EST
Created attachment 557296 [details]
patch from upstream commit 2d80bda39073a35af4b904d27fa1511cd309b26f
Comment 17 Jeff Law 2012-01-24 16:44:27 EST
I resync'd the glibc-ports code from the master sources which ought to fix this problem.
Comment 18 Peter Robinson 2012-01-25 04:38:23 EST
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.