https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> --- JFTR, I did an experiment with a trivial hot/cold partitioned object and ld64 from XCode10.1. Yes, it complains - but it still publishes the symbol as a weak extern. ==== I looked a bit harder at the symbol resolutions you attached. * In the working case, the libsupc++ (part of libstdc++) versions of the various new functions/operators are overriding the ones from libc++abi (because the libstdc++.dylib is presented first, I assume). * In the non-working case, the various new functions/operators are some resolved from the static instances [static_1.exe:__Zblahblah] - and some from libc++abi. This is exactly the kind of fragility I was concerned about. e.g. dyld: weak bind: static_1.exe:0x10E034738 = static_1.exe:__ZnamRKSt9nothrow_t, *0x10E034738 = 0x10DD4E540 dyld: weak bind: libstdc++.6.dylib:0x112FC0980 = static_1.exe:__ZnamRKSt9nothrow_t, *0x112FC0980 = 0x10DD4E540 dyld: weak bind: libc++abi.dylib:0x7FFF8C76F0A0 = libc++abi.dylib:__ZnamSt11align_val_t, *0x7FFF8C76F0A0 = 0x7FFF578B9C9D dyld: weak bind: libstdc++.6.dylib:0x112FC0988 = libc++abi.dylib:__ZnamSt11align_val_t, *0x112FC0988 = 0x7FFF578B9C9D dyld: weak bind: static_1.exe:0x10E034740 = static_1.exe:__Znwm, *0x10E034740 = 0x10DD4E500 dyld: weak bind: liblcio.2.12.dylib:0x1125F0E08 = static_1.exe:__Znwm, *0x1125F0E08 = 0x10DD4E500 and .. dyld: weak bind: libstdc++.6.dylib:0x112FC0990 = static_1.exe:__Znwm, *0x112FC0990 = 0x10DD4E500 dyld: weak bind: libc++abi.dylib:0x7FFF8C76F0B0 = libc++abi.dylib:__ZnwmSt11align_val_t, *0x7FFF8C76F0B0 = 0x7FFF578B9BE7 dyld: weak bind: libstdc++.6.dylib:0x112FC0998 = libc++abi.dylib:__ZnwmSt11align_val_t, *0x112FC0998 = 0x7FFF578B9BE7 dyld: lazy bind: libgfortran.5.dylib:0x1128D75D0 = libsystem_pthread.dylib:_pthread_key_create, *0x1128D75D0 = 0x7FFF5A38270C If you look at the working case, these all seem to be consistently resolved from libstdc++.dylib (there's a lot of data, I don't claim to have checked every entry, but a portion). === Finally, I don't think that there's been any change to the build of libstdc++ that would actually have changed anything about that particular circumstance (the warning given) in the period mentioned. ** It *is* possible that there's been some change to the system dyld [dynamic linker] during that time as part of an OS upgrade (but not sure if there was an upgrade over that period either) that has tightened up some aspect of the symbol binding - but not sure how to prove/disprove that right now.
