https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Francois-Xavier Coudert from comment #9) > Some more debugging, and finally a victory: I understand what happens. But I > don't know how to fix it. > > 0. With my testcase from comment #8, compiling with -static-libgcc makes the > executable have the desired behavior (abort), but compiling without it (or > with -shared-libgcc) makes it not abort. > > 1. Yet forcing to compile with the "shared" object file (_addvsi3_s.o) leads > to correct result (abort). So, it's not a miscomputation. Great! > 2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows > that it's loading the correct libgcc_s: > > dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib > > > 3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does > not get pulled from libgcc_s.1.dylib, as we'd like, but from the system's > libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol > for backward compatibility reasons): > > dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3, > *0x10D212010 = 0x7FFF9158BF67 > > > > > 4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by > saying "DYLD_FORCE_FLAT_NAMESPACE=y > DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib", makes the > executable have the expected behavior (aborts). > > ----------------------------------- > > Conclusion: it's really a darwin bug. We need to have symbols taken from our > own libgcc override those from the system's libcompiler_rt (which is itself > pulled from libSystem, if I understand correctly). Any idea how we achieve > that? ld64 should pull the symbol from the first place that mentions it on the link line. It should place the two-level namespace information in the exe so that the symbol is resolved from the correct place at runtime. Can you confirm this? if that's the case potential solutions: (a) more fiddling with library ordering in the specs (b) we could punt on the hope of ever getting the "extension" shared library to play nicely with the already installed stuff and revert to putting these items in a "crt". This would be a static lib and mentioned on the link-line would take precedence over the system ones. *sigh* also on my TODO is tidying up the maze of twisty passages that constitutes the crt/libgcc_s/libcc_ext support across the darwin patch. This is where we have a huge challenge c.f. other systems since it's not acceptable for end Users to "just install some new libs into some part of /usr/xxxx as root". Thus we have to make whatever we do interact well with what's already there.
