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):
Steps to Reproduce:
1. rpmbuild --rebuild rust-1.19.0-2.fc27.src.rpm
(sorry I don't have a smaller reproducer)
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)
/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'
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.
Testing the exact same system with binutils-2.28-14.fc27 is fine.
Also reported upstream, with binaries available for comparison:
And a similar error in other packages was reported here:
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.
This error comes out when i run *simpletest for testing MUMPS-5.1.1 MPI
libraries on PowerPC-64 'Little Endian' arch only:
./dsimpletest: error while loading shared libraries:
../lib/libmumps_common-5.1.1.so: expected localentry:0 `pthread_cond_init'
System: Fedora 27 (devel branch)
Architecture: PowerPC 64 'Little Endian'
Even libsbml F27 rebuild is affected on ppc64le only:
------- 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.
(In reply to IBM Bug Proxy from comment #4)
> ------- Comment From email@example.com 2017-07-28 07:07 EDT-------
> This is upstream glibc bug
> 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
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.
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...
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.
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.
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:
/usr/bin/cmake: error while loading shared libraries: /lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
Should I open a different bugreport?
(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.
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
Package rebuilds are done, and the issue should be resolved by now:
This might be causing another issue. Please see bug #1479031.
*** Bug 1479031 has been marked as a duplicate of this bug. ***
Never mind, bug #1479031 is actually the same issue which is already resolved. Thanks.