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
