Hide Forgot
Description of problem: glibc fails to build on powerpc Version-Release number of selected component (if applicable): glibc-2.15-1.fc17 How reproducible: always Steps to Reproduce: 1. ppc-koji build --scratch glibc-2.15-1.fc17.src.rpm Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=358475 Additional info: this is currently blocking the mass rebuild on powerpc,
OT, gcc currently doesn't seem to rebuild either, while I've fixed a profiledbootstrap failure, now there seems to be buggy (possibly miscompiled, who knows) doxygen, at least http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=361424 looked (until I've cancelled it) like stuck doing doxygen forever. And the baseurl=http://ppc.koji.fedoraproject.org/mash/rawhide/ppc64/os/ mock doesn't like to rebuild gcc either, yum complains about missing /usr/share/java/eclipse-ecj.jar.
the older gcc builds just fine and even doxygen had no problems at all. It looks like there's an issue with the new gcc as doxygen loops while looking for input files, p.e. lstat64("include", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 getcwd("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3", 4096) = 96 access("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3/include/stdalign.h", F_OK) = -1 ENOENT (No such file or directory) access("include", F_OK) = 0 lstat64("include", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 getcwd("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3", 4096) = 96 access("/builddir/build/BUILD/gcc-4.7.0-20120123/obj-ppc64-redhat-linux/ppc64-redhat-linux/libstdc++-v3/include/stdalign.h", F_OK) = -1 ENOENT (No such file or directory) This repeats again and again until it gets killed. There are no header files in that directory so there are two bugs: doxygen should handle that more gracefully and gcc needs to put the files where it tells doxygen to look for them,
But the same src.rpm built just fine on all other arches. Anyway, I see that gcc-4.7.0-0.9.fc17 built, did you need to tweak it in any way?
I've updated the repository at http://ppc.koji.fedoraproject.org/mash/rawhide/ppc64/os/, please try again with yum. I've tried to build the latest glibc again on my power7 now that you've built gcc-4.7.0-0.10.fc17, but glibc-2.15-1 still fails with the same error.
I'm looking into it.
-fno-inline-functions is no longer enough to prevent gcc from inlining call_gmon_start into _init while compiling sysdeps/generic/initfini.c. The inlined function has a branch to the end, but the branch is in the PROLOG portion whereas the label ends up in the EPILOG portion, and each portion is assembled separately. We need -fno-inline-functions-called-once (a new flag) to get the intended behavior. Arguably, -fno-inline-functions should imply -fno-inline-functions-called-once, but that's not what it does ATM.
Couldn't we add a noinline attribute to call_gmon_start? Just looking at other alternatives...
I'd think so, but perhaps for the future GCCs you need noclone attribute too in case some GCC version decides to clone it.
s/-fno-inline-functions/-fno-inline/ in initfini build rules is the solution glibc is going with, patch pending. IBM had run into this and worked around it by adding -fno-inline to CFLAGS-initfini.s in sysdeps/powerpc/powerpc64/Makefile http://sourceware.org/ml/libc-alpha/2012-01/msg00195.html has the work-around patch.
Thanks Alex (& Ryan). I've installed the change into rawhide, so the next round of PPC builds will hopefully run without a hitch. Obviously if Uli checks in something different upstream I'll update the Fedora patch appropriately.
I don't think there was acknowledgement to my solution (patch). Alexandre, if you feel that my patch solves the particular problem at hand then please comment on the ml. I'll then resubmit to libc-alpha to make sure it's the desired solution. In the bug I created the patch for we were seeing init branching directly to fini due to aggressive inlining.