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.