https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172
--- Comment #26 from Gubbins <dave.gittins at gmail dot com> --- If anyone is interested, I received the following response on my bug report with Apple. > This issue behaves as intended based on the following: > > The program produced by ld64 seems fine: > > [/tmp/35663253]> nm -nm foo > (undefined) external __Unwind_Resume (from libSystem) > (undefined) external > __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE8overflowEi (from libstdc++) > (undefined) external __ZNSt6localeC1Ev (from libstdc++) > (undefined) external __ZNSt6localeD1Ev (from libstdc++) > (undefined) external __ZTVSt15basic_streambufIcSt11char_traitsIcEE (from > libstdc++) > (undefined) external __ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE (from > libstdc++) > (undefined) weak external __ZdlPv (from libstdc++) > (undefined) external ___gxx_personality_v0 (from libstdc++) > (undefined) external dyld_stub_binder (from libSystem) > 0000000000001000 (absolute) [referenced dynamically] external > __mh_execute_header > 0000000000001dee (__TEXT,__text) weak external > __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED1Ev > 0000000000001e3f (__TEXT,__text_startup) external _main > 0000000000002060 (__DATA,__gcc_except_tab) non-external GCC_except_table0 > 0000000000002080 (__DATA,__data) weak external > __ZNSs4_Rep20_S_empty_rep_storageE > > [/tmp/35663253]> dyldinfo -weak_bind foo > weak binding information: > segment section address type addend symbol > __DATA __got 0x00002010 pointer 0 __ZNSs4_Rep20_S_empty_rep_storageE > __DATA __la_symbol_ptr 0x00002040 pointer 0 > __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED1Ev > __DATA __la_symbol_ptr 0x00002058 pointer 0 __ZdlPv > __DATA __la_symbol_ptr 0x00002058 pointer 0 __ZdlPv > > The problem has to do with __ZNSs4_Rep20_S_empty_rep_storageE. That symbol is > also in libstdc++.6.dylib and is expected to be coalesced. > > [/tmp/35663253]> nm -m libstdc++.6.dylib | grep > __ZNSs4_Rep20_S_empty_rep_storageE > 0000000000137020 (__DATA,__pu_bss5) extern > al __ZNSs4_Rep20_S_empty_rep_storageE > > 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.
