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 1475636 - ppc64le: expected localentry:0 `pthread_condattr_destroy'
Summary: ppc64le: expected localentry:0 `pthread_condattr_destroy'
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: ppc64le
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1479031 (view as bug list)
Depends On: 1406172
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2017-07-27 04:03 UTC by Josh Stone
Modified: 2017-08-07 21:15 UTC (History)
17 users (show)

Fixed In Version: binutils-2.29-3.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-31 15:26:47 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 157023 0 None None None 2019-06-20 15:33:02 UTC
Sourceware 21847 0 P2 RESOLVED ppc64le: expected localentry:0 `pthread_…' ld.so error prevents allocation startup 2021-01-13 09:21:17 UTC

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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.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 T. (sagitter) 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 T. (sagitter) 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 amodra.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 amodra.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.

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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EUG7DCCNATVM72TQYUH3Q2PY53I7AR6V/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.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. ***
Comment 15 Endi Sukma Dewata 2017-08-07 21:15:59 UTC 
Never mind, bug #1479031 is actually the same issue which is already resolved. Thanks.
Note You need to log in before you can comment on or make changes to this bug.