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

[Shankar Easwaran]

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 ?

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

Thanks

Shankar Easwaran

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