|Summary:||ppc64le: expected localentry:0 `pthread_condattr_destroy'|
|Product:||[Fedora] Fedora||Reporter:||Josh Stone <jistone>|
|Component:||binutils||Assignee:||Nick Clifton <nickc>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||agk, anto.trande, dan, edewata, fweimer, hannsj_uhl, jakub, kdudka, mattia.verga, mtasaka, negativo17, nickc, redhat-bugzilla, rosset.filipe, tpopela, tulioqm, zbyszek|
|Fixed In Version:||binutils-2.29-3.fc27||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-07-31 15:26:47 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1406172|
Description Josh Stone 2017-07-27 04:03:19 UTC
Description of problem: Since the update to binutils 2.29, rust fails to build on ppc64le with: error while loading shared libraries: ... expected localentry:0 `pthread_condattr_destroy' Version-Release number of selected component (if applicable): binutils-2.29-1.fc27 How reproducible: 100% Steps to Reproduce: 1. rpmbuild --rebuild rust-1.19.0-2.fc27.src.rpm (sorry I don't have a smaller reproducer) Actual results: As seen here: https://koji.fedoraproject.org/koji/taskinfo?taskID=20725487 Copying stage1 compiler (powerpc64le-unknown-linux-gnu) Building stage1 std artifacts (powerpc64le-unknown-linux-gnu -> powerpc64le-unknown-linux-gnu) error: process didn't exit successfully: `/builddir/build/BUILD/rustc-1.19.0-src/build/bootstrap/debug/rustc -vV` (exit code: 127) --- stderr /builddir/build/BUILD/rustc-1.19.0-src/build/powerpc64le-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: /builddir/build/BUILD/rustc-1.19.0-src/build/powerpc64le-unknown-linux-gnu/stage1/lib/libstd-9ccbef306c00437d.so: expected localentry:0 `pthread_condattr_destroy' Expected results: A successful build. If you get past "Building stage1 std artifacts" then it's probably going to be fine as far as this bug goes. Additional info: Testing the exact same system with binutils-2.28-14.fc27 is fine. Also reported upstream, with binaries available for comparison: https://sourceware.org/ml/binutils/2017-07/msg00272.html And a similar error in other packages was reported here: https://firstname.lastname@example.org/message/N3YWVWNNQSIIJU5TIXYWD5C3RLDIO4LV/
Comment 1 Kamil Dudka 2017-07-27 09:17:56 UTC
I have similar problem with libcurl and cmake. If libcurl is rebuilt while binutils-2.29-2.fc27.ppc64le is installed on the system, cmake fails to start with the following error: cmake: error while loading shared libraries: /lib64/libcurl.so.4: expected localentry:0 `pthread_mutex_destroy' I tried to rebuild cmake to fix it but I get the above error also during the build of cmake (while running %install). If I downgrade to binutils-2.28-14.fc27.ppc64le, rebuild libcurl and isntall, then I am able to run and build cmake again.
Comment 2 Antonio Trande 2017-07-27 09:20:32 UTC
This error comes out when i run *simpletest for testing MUMPS-5.1.1 MPI libraries on PowerPC-64 'Little Endian' arch only: >> + export LD_LIBRARY_PATH=/builddir/build/BUILD/MUMPS_5.1.1/MUMPS-5.1.1-openmpi/examples:../lib:/usr/lib64/openmpi/lib + LD_LIBRARY_PATH=/builddir/build/BUILD/MUMPS_5.1.1/MUMPS-5.1.1-openmpi/examples:../lib:/usr/lib64/openmpi/lib + ./dsimpletest ./dsimpletest: error while loading shared libraries: ../lib/libmumps_common-5.1.1.so: expected localentry:0 `pthread_cond_init' << System: Fedora 27 (devel branch) Build log: https://kojipkgs.fedoraproject.org//work/tasks/7804/20767804/build.log Architecture: PowerPC 64 'Little Endian' List dependencies: https://kojipkgs.fedoraproject.org//work/tasks/7804/20767804/root.log
Comment 3 Antonio Trande 2017-07-27 09:48:23 UTC
Even libsbml F27 rebuild is affected on ppc64le only: https://koji.fedoraproject.org/koji/getfile?taskID=20791922&volume=DEFAULT&name=build.log&offset=-4000
Comment 4 IBM Bug Proxy 2017-07-28 11:10:23 UTC
------- Comment From email@example.com 2017-07-28 07:07 EDT------- This is upstream glibc bug https://sourceware.org/bugzilla/show_bug.cgi?id=21847 I expect this means the localentry:0 optimization will need to be disabled. It might be possible to come up with a clever solution that detects a broken glibc.
Comment 5 Florian Weimer 2017-07-28 11:47:21 UTC
(In reply to IBM Bug Proxy from comment #4) > ------- Comment From firstname.lastname@example.org 2017-07-28 07:07 EDT------- > This is upstream glibc bug > https://sourceware.org/bugzilla/show_bug.cgi?id=21847 > > I expect this means the localentry:0 optimization will need to be disabled. > It might be possible to come up with a clever solution that detects a broken > glibc. To clarify: This optimization is not compatible with the way we currently build our distributions, and to me, it seems it goes against the spirit of the ELF specification.
Comment 6 Kamil Dudka 2017-07-28 13:01:48 UTC
I tried to rebuild libcurl with -Wl,--no-plt-localentry on ppc64le but the build failed because the configure script checks run-time linking of openldap, which is now also broken. So even if binutils is fixed, we will need to rebuild multiple libraries bottom up, as I understand it...
Comment 7 Nick Clifton 2017-07-28 15:38:50 UTC
Hi Guys, I have created an updated rawhide binutils which disables the plt_localentry0 optimization by default. (It can still be enabled via the linker command line). In order for the patched linker to be effective however another mass rebuild is needed, so I have put in a request for this to happen. Cheers Nick
Comment 8 Josh Stone 2017-07-28 17:58:55 UTC
On my test system, which hasn't updated any other broken libraries, a rust rebuild is working fine with binutils-2.29-3.fc27.ppc64le.
Comment 9 Mattia Verga 2017-07-29 07:28:59 UTC
I've just see this problem on Rawtherapee rebuild. Seems that binutils-2.29-3.fc27.ppc64le doesn't fix it, but the error message is slightly different: https://koji.fedoraproject.org/koji/taskinfo?taskID=20826727 /usr/bin/cmake: error while loading shared libraries: /lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate' Should I open a different bugreport?
Comment 10 Kamil Dudka 2017-07-29 08:29:46 UTC
(In reply to Mattia Verga from comment #9) > Should I open a different bugreport? Nope. It is just that the libraries you link against need to be rebuilt first.
Comment 11 Nick Clifton 2017-07-31 13:35:05 UTC
Hi Guys, I have updated the rawhide binutils rpm again (binutils-2.29-5.fc27). For this change I have brought in both of the patches made by Alan Modra to the upstream FSF sources in respect of this problem, so I hope that once another mass rebuild has finished, the issue should be resolved. Cheers Nick
Comment 12 Florian Weimer 2017-07-31 15:26:47 UTC
Package rebuilds are done, and the issue should be resolved by now: https://email@example.com/message/EUG7DCCNATVM72TQYUH3Q2PY53I7AR6V/ https://firstname.lastname@example.org/message/HESPVPZVI6HFS4NSQ3WWMYEFEVUCKXEK/
Comment 13 Endi Sukma Dewata 2017-08-07 19:01:24 UTC
This might be causing another issue. Please see bug #1479031.
Comment 14 Endi Sukma Dewata 2017-08-07 21:12:56 UTC
*** Bug 1479031 has been marked as a duplicate of this bug. ***