[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[iains at gcc dot gnu.org]

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..