[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 #26 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #25)
> (In reply to Richard Biener from comment #24)
> > (In reply to Iain Sandoe from comment #23)
> > > (In reply to Jürgen Reuter from comment #22)
> 
> > 
> > Indeed - somehow you didn't get a statically linked executable.  Quoting the
> > full final link command would be interesting.
> 
> The full link commands can be found here, I believe: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750#c14
> 
> Our code generates code for particle physics simulations in the form of
> dynamic libraries that get linked and loaded. For batch clusters, we
> attempted to provide static binaries for these simulations, however, we have
> order 10-15 external libraries that can be linked to our code (which are
> partially mandatory). There are some of them which only exist as dynamic
> libraries, so there our approach cannot result in a purely static binary.
> The static stdc++ library is sucked in via the libtool link mode/flag
> -static-libtool-libs while the dynamic ones are sucked in via the external
> C++ libraries that are available only dynamically.

So .. I appreciate it can be difficult with a sophisticated project.  However,
it would seem prudent to try to arrange that you have only one instance of the
c++ library.  Imagine creating an object in one instance, and that object
somehow finds it's way to be destroyed in a different one.

I've spent some time trying to make it possible to link GCC Darwin projects
'statically', (modulo the libSystem, which must be dynamic) - but that's only
going to work if all the project dependent libs are available as convenience
libs (or, I suppose, if no used dynamic ones have any external deps other than
libSystem).

If that's not possible, then it's most likely better to arrange to do a link -r
on everything that can be found as convenience .. and then link the result with
-lstdc++.

It might be that it worked before mostly from luck - although I'd still like to
have a reference for a known "working" static linked case.  As the c++ library
grows, this is only going to be more fragile.