https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jürgen Reuter from comment #14) does the application use exceptions? > This one is failing: > gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o > static_1.exe .libs/static_1.exe_prclib_dispatcher.o <snip> > /usr/local/lib/libstdc++.a ^^^ please confirm that this is from the "current compiler build". <snip> > -L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/ > libsupc++/.libs -lm ^^^^ note - no "-lSystem -lgcc_ext.10.5" (which is what I'd expect). > > while that one is working: > > gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o > static_1.exe .libs/static_1.exe_prclib_dispatcher.o <snip> > libsupc++/.libs -lSystem -lgcc_ext.10.5 /usr/local//lib/libHepMC.a -lstdc++ > -llcio -lm ^^^^^^^ this looks like the build process in this case is adding libs that the compiler driver normally adds ( they are not present in the case above ). * If you can extract these two fortran link lines - and then execute them separately in the build dir with "-v" so that we can see the output of the compiler-driver's internal link line and what its search paths are. * According to your posted otool output, the version of libstdc++.dylib that is bound is the one in /usr/local/lib/ which is where you pick up the static lib in the non-working case. * The object files used to build the static (.a) and dynamic (.dylib) versions of libstdc++ are the same, so we really need to pin down where the issue occurs. * DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 <exe> will show you which libraries are used, and from which library each symbol is resolved - it probably will produce a lot of output..
