Safe to link to static libstdc++ from shared library?

[Fredrik Orderud]

On Fri, Nov 14, 2025 at 2:52 PM Jonathan Wakely <jwakely@redhat.com> wrote:
> On Fri, 14 Nov 2025 at 13:45, Fredrik Orderud <forderud@gmail.com> wrote:
> > I'm working on a project developing a Linux shared library (.so) with
> > a pure "C" interface that we want to be as widely compatible as
> > possible with multiple distros of various age. The -static-libstdc++
> > option therefore seemed attractive, since it appear to eliminate
> > run-time dependencies to libstdc++. We've therefore used
> > -static-libstdc++ together with -Wl,--exclude-libs,ALL in an attempt
> > to encapsulate all C++ dependencies (and other 3rd party libraries),
> > so that callers doesn't need to know about the C++ stuff inside the
> > shared library.
> >
> > This worked fine for a while, but now we suddenly started experiencing
> > segmentation faults when calling std::async from the shared lib. I'm
> > not sure if this is a caused by a bug, a known limitation or our
> > misunderstanding of the libstdc++ documentation. A minimal reproducer
> > is available on
> > https://github.com/forderud/UnixSharedLib/tree/main/static-libstdc%2B%2B
> >
> > ASK: Are there any documented or undocumented limitations on
> > -static-libstdc++ usage when building shared libraries on Linux?
>
> The problem is your use of --exclude-libs - that won't work.
>
> You can't pretend there are no dependencies on the C++ runtime like
> that, the symbols in libstdc++ need to be globally visible so that the
> linker can properly resolve them across different ELF objects.

Ok, so what we're doing is supported if we just let the libstdc++
symbols "leak out" from our shared library?

If so, then will we still avoid run-time dependencies to the
distro-provided libstdc++?

Also, will it be safe for the client executable to potentially use a
different libstdc++ version than what's used in our shared library?

Fredrik