[PATCH] [ELF] Fix undefined symbol handling in DSO.

Shankar Easwaran shankare at codeaurora.org
Mon Apr 7 12:53:10 PDT 2014


On 4/7/2014 2:27 PM, Joerg Sonnenberger wrote:
> (2) Undefined symbols in shared libraries pulled in via -l are ignored.
>> By "ignored", I'd think you mean "undefined symbol from library is not
>> fatal", right?
> No, I really meant ignored. The most you can or should do about them is
> check for consistency of the type. Otherwise they are completely
> irrelevant. Trying to resolve them is just going to waste time.
The undefined symbol from a shared library may most likely pull in a 
defined symbol from an archive library which comes later in the link 
line and the executable may end up exporting it.

I am not sure what you meant by ignored ?

>> (3) For ELF, shared libraries are processed recursively.
>>
>> Are you talking about runtime behavior? Could you elaborate a bit?
> No, link time behavior. GNU folks decided to break this in recent
> versions, but ELF has a recursive namespace and the linker should
> implement that. A simple case is linking against OpenSSL's libssl. That
> one is linked against libcrypto. For that reason, adding -lssl does
> add the symbols from libcrypto.so as well. Searching is controlled by
> the combination of libssl.so's rpath and the -rpath-link flags.
I thought this would be the right way, as libraries looked up during 
runtime and linktime can be totally different.

LD_LIBRARY_PATH/$ORIGIN can play a role here, no ?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation




More information about the llvm-commits mailing list