This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ppc64le: expected localentry:0 `pthread_condattr_destroy'


On 07/26/2017 09:04 PM, 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

Well, the only place the rust std library uses this function is in it's
own Condvar wrapper, and it's called through an FFI declaration without
any stub.  I can write a trivial program that creates a Condvar, and it
links and executes just fine.  I even verified that the call is really
made with ltrace.  So I can at least say the way rust is linking this is
not *totally* broken.

I also found that "ldd -r ./lib/libstd-c3a1748e15265da7.so" is just
fine, but "ldd -r ./bin/rustc" gives the error in libstd again.  That
rustc binary is basically just a shim that calls librustc_driver, but
"ldd -r" on that library also has no error.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]