On 7/13/2026 9:34 AM, Ziyang Zhang wrote:
On Mon, 13 Jul 2026 08:31:18 -0700, Pierrick Bouvier wrote:
The problem is that if that the guest program, or the host library
(host
libhello) may depend on libstdc++. If they do and if they depend on a
(newer) symbol not present in lorelei libstdc++, we break ABI. Same
goes
for libgcc.
By not doing this, you'll be forced to provide a lorelei devkit
everytime a new libstdc++ is published, or a distribution updates its
gcc.
The only solution is to embed libstd++ and libgcc statically, or
rely on
host libraries. If you choose the second option, you know have the
opposite problem. So I think the only way to solve it is really static
linking, even if it will slightly increase binaries size.
The devkit already ships libstdc++ and libgcc anyway: its own clang/
LoreTLC link them dynamically, and we bundle them so the toolchain even
starts. So bundling libstdc++ for the thunk flow adds no new dependency,
it just reuses one the devkit must carry. Static-linking the thunks
wouldn't make the devkit any smaller or more self-contained either,
since clang still needs the dynamic libstdc++; we'd only be adding
static copies on top of it.
There is a difference between the toolchain dependencies, and thunks
dependency. For the first one, it's perfectly find to provide libstdc++,
for the second, it can create conflicts at runtime that may be very hard
to diagnose and solve.
On the ABI risk itself: libstdc++ keeps a backward-compatible ABI, and
the copy we bundle is recent, so a thunked host library only breaks if
it was built against a strictly newer libstdc++ and references a new
symbol. Even then it needs no new devkit, because the resolution order
is the integrator's to choose. On a host newer than our bundle, putting
the system libstdc++ ahead of the devkit's on LD_LIBRARY_PATH lets the
host library bind the newest one, while clang and the Lorelei runtime
keep working against it by backward compatibility. So a gcc update on
the host doesn't force us to reship.
Sure can choose indeed. However, he has to find where such libraries are
located on his system, and prepend that to LD_LIBRARY_PATH. Not the most
user-friendly thing to guess and debug IMHO.
There's also an active reason not to static-link. Both the Lorelei
runtime and the generated thunk libraries depend on libstdc++. If we
statically link libstdc++ into a thunk while the host library it
dispatches to links the system libstdc++ dynamically, the process ends
up with two libstdc++ copies on the host side, right across the boundary
where C++ objects and exceptions pass between the thunk and the real
library. That can break:
- Exceptions: one thrown in the host library may not be caught in the
thunk. The two copies have different std::type_info for the same type,
so the match fails and it hits std::terminate.
- dynamic_cast / typeid across the boundary: they assume a single
type_info per type, so they can start returning null or misidentifying
types.
- Duplicated global state: two sets of the iostream objects, the locale/
facets, and the exception emergency buffer.
That's a good point, but does lorelei even provide a solution for that?
I guess that exception raised from an host library and sent back to
guest binary with target specific types will not result in what is
expected at the moment.
Based on the above reasons, I prefer to do that than statically link and
grow the big artifact. Does that hold for you?
Ok.
Thanks,
Ziyang Zhang
Regards,
Pierrick
