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.