[Bug c++/87380] New: Explicit instantations should use weak symbols on darwin

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87380

            Bug ID: 87380
           Summary: Explicit instantations should use weak symbols on
                    darwin
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Keywords: ABI
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
                CC: mikestump at comcast dot net
  Target Milestone: ---
            Target: *-*-darwin*

The response from Apple quoted in 82172 comment 26 says that explicit
instantiation definitions in a dylib need to be weak symbols, otherwise they
won't be merged with other copies of the same symbol in other translation
units:

> The problem is that it is not “weak” in libstdc++.6.dylib. It is a regular
> exported symbol. If it were weak, then at runtime dyld would coalesce it with
> the one in the program “foo”.
> 
> macOS does not use “flat namespace”. It uses two level namespace where every
> symbol found in a dylib at build time has the dylib in which it was found
> recorded and at runtime dyld only looks there. The exception to this is weak
> symbols, where dyld looks across all dylibs and picks one, then adjusts all
> uses in all dylibs to use that choosen one.
> 
> The static linker (ld64) knows those rules and when building a dylib that
> exports a non-weak symbol, the linker optimizes all uses within that dylib
> to directly use that symbol. That is what is happening in libstdc++.6.dylib.
> __ZNSs4_Rep20_S_empty_rep_storageE is not weak, so when libstdc++.6.dylib all
> uses of __ZNSs4_Rep20_S_empty_rep_storageE are directly bound to use the copy
> in libstdc++.6.dylib. There is nothing dyld can do at runtime to change that.
> 
> The fix here is that __ZNSs4_Rep20_S_empty_rep_storageE needs to be weak when
> libstdc++.6.dylib is built.