This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ppc64le: expected localentry:0 `pthread_condattr_destroy'
On 07/27/2017 11:55 AM, Florian Weimer wrote:
> On 07/27/2017 06:04 AM, Alan Modra wrote:
>>>>> On 07/25/2017 09:11 PM, Josh Stone wrote:
>>>>>> ./bin/rustc: error while loading shared libraries:
>>>>>> ./lib/libstd-c3a1748e15265da7.so: expected localentry:0
>>>>>> `pthread_condattr_destroy'
>>
>> You will get this error if the link-time version of a function symbol
>> is seen as localentry:0 (ie. not needing a global entry point due to
>> not needing a valid r2 toc pointer), but the run-time version does.
>>
>> The most likely thing is that your library was linked against a stub
>> version of pthread_condattr_destroy. Making the stub weak will
>> disable the generation of the optimized localentry:0 plt call code.
>> So will linking with -Wl,--no-plt-localentry
>
> The common theme seems to be that this only affects symbols which live
> both in libpthread and libc. Do you suggest that we have to make the
> implementation in libc a weak symbol?
>
> Why isn't this a plain regression break ELF symbol interposition?
>
> I filed a glibc bug for this:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21847
>
> I think we need to sort this out before the release. That does not mean
> we have to fix it, we just need a better understanding what is going on.
I injected -Wl,--no-plt-localentry into the build, using this patch:
--- a/sysdeps/powerpc/powerpc64le/Makefile
+++ b/sysdeps/powerpc/powerpc64le/Makefile
@@ -6,6 +6,10 @@
# linked executables, forcing to link the loader after libgcc link.
f128-loader-link = $(as-needed) $(elf-objpfx)ld.so $(no-as-needed)
+sysdep-LDFLAGS += -Wl,--no-plt-localentry
+# Linking libc_pic.os ignores sysdep-LDFLAGS.
+LDFLAGS-c_pic.os += -Wl,--no-plt-localentry
+
ifeq ($(subdir),math)
# sqrtf128 requires emulation before POWER9.
CPPFLAGS += -I../soft-fp
But the issue persists afterwards. I'm afraid we'll need a real fix.
Thanks,
Florian