[lld] r195307 - [LinkingContext] Limit shared library undefined atoms to be added.

[Nick Kledzik]

On Nov 21, 2013, at 10:35 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> On 11/21/2013 11:30 AM, Nick Kledzik wrote:
>> On Nov 20, 2013, at 7:50 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>> 
>> +  /// Add undefined symbols from shared libraries ?
>> +  virtual bool addUndefinedAtomsFromSharedLibrary(const SharedLibraryFile *) {
>> +    return true;
>> +  }
>> +
>> FYI, MacOSX and iOS use something we call two-level-namespace wherein each imported symbol
>> is marked with the dylib it was found in at static link time.  At runtime, the loader (dyld) only looks in
>> that symbol in that dylib.  Therefore, there is no need to check undefined symbols in DSOs (dylibs)
>> at static link time.
> I am trying to understand in a bit more detail here.
> 
> For example: If I have the below link line
> 
> ld 1.o libx.so libpthread.a
> 
> and say libx.so has a undef for pthread_create, and a definition from libpthread.a that resolves pthread_create, does the MacOSX / iOS model export the definition of pthread_create from the executable that was created ?
When libx.so was built, it would fail to link unless there was a definition of pthread_create somewhere.  If it was in a dylib (dso), the name of that dylib would be recorded  in libx.so with the undefined symbol for pthread_create.  So when your link line is run, there is no need to load  pthread_create from libpthread.a because libx.so already knows where to find it.


> 
>> So, the MachOLinkingContent will be returning false for addUndefinedAtomsFromSharedLibrary(),
> Oh, so MachOLinkingContext could override that function and return false.
Yes.  Thanks for adding that capability.

-Nick