On Mon, 13 Jul 2026 10:53:56 -0700, Pierrick Bouvier wrote:
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.
Currently, the Lorelei host runtime disables exceptions. However, it is
possible that the host thunk library enables exceptions, and these
exceptions should be caught by the host library.
Additionally, in the Lorelei guest/host runtime, there is a logging
module. Therefore, if the stdout buffer of the host library is not
consistent, the output will become disordered.
