Hi,
On Fri, 10 Jul 2026 15:57:52 -0700, Pierrick Bouvier wrote:
Great work, the workflow is now ready!
A few small issues are left with lib dependencies.
libstdc++
---------
LD_LIBRARY_PATH=$DEVKIT/lib:build/host \
./build/qemu-x86_64 -plugin ./build/contrib/plugins/libdlcall.so \
-E LD_LIBRARY_PATH=$DEVKIT/x86_64/lib:thunks/x86_64 \
-L /usr/x86_64-linux-gnu/ \
build/guest/main
build/guest/main: error while loading shared libraries: libstdc++.so.6:
cannot open shared object file: No such file or directory
Indeed, libstc++ is not available in machine's x86_64 sysroot by
default. It works with -L $DEVKIT/x86_64/sysroot but as mentioned
previously, we don't want to use another sysroot than the one that user
has, since it can contain extra libraries we are not aware about (or
Lorelei one can bring extra dependencies that we don't want).
So the last thing needed is to link statically libstdc++ for guest thunk
and host thunk. In addition, you can do it for lorelei .so (I mean .so
included in devkit), so thunking is fully self contained and does not
require extra dependencies from the system where it runs.
Same for libgcc.
Link parameters you need are -static-libstdc++ -static-libgcc.
Once added, all thunks and lorelei devkit should be portable between
different machines 👍.
The only base dependency we can assume will be present is libc (which
also includes libm.so).
We could argue if c++ should be considered as a base dependency also.
For debian (+ubuntu), fedora and archlinux, it's not.
See what is included in debian libc package. For instance, in our case:
https://packages.debian.org/trixie/all/libc6-amd64-cross/filelist
doc
---
While at it, please add -L /usr/x86_64-linux-gnu/ to command line so it
matches the default people will use.
rpath
-----
It seems that .so in thunks have rpath set to $ORIGIN:$ORIGIN/../../lib,
which should not be needed. LD_LIBRARY_PATH will specify where to find
the correct libraries, please remove it.
You can use this command to double check this:
readelf -d thunks/libhello_HTL.so thunks/x86_64/libhello.so
No RUNPATH should be present.
thunks/libhello_HTL.so has an explicit dependency to
build/host/libhello.so. It should not include build/host and just link
to libhello.so. Remove rpath also.
thunks/x86_64/libhello.so, remove rpath.
To clarify, lorelei-devkit-*/*/lib/* can use rpath since devkit itself
is self contained. Thunks can not.
-----
Once solved, we'll have a clean and minimal workflow, which ensure
thunks do not require any extra dependency.
With this, any user will be able to grab a lorelei devkit + a thunk
tarball and use it as a drag and drop replacement for their system
libraries, as long as it matches their version of course.
Keep up the good work!
Pierrick
Thanks for the careful review.
On libstdcxx / libgcc: rather than static-linking them into every thunk, I'd
prefer to bundle the shared libraries in the devkit and let the thunks link
against them dynamically. The reasoning:
The devkit already has to carry libstdcxx for LoreTLC itself, which is a
large
C++ program. Shipping it once as a shared library and having the guest and
host thunks link that same copy avoids baking a static libstdc++ into every
thunk, and keeps LoreTLC and the thunks on one runtime.
The portability you're after is preserved. libstdc++.so.6 and libgcc_s.so.1
sit beside the lorelei runtimes (the devkit's host lib/ and guest
x86_64/lib/),
so they are found on the same LD_LIBRARY_PATH the run already sets. A clean
Fedora or Arch container with only libc installed runs a devkit + thunk pack
directly, nothing else needed. The one base dependency we assume is still
libc. The devkit brings its own libstdcxx and libgcc.
So static vs dynamic doesn't change what the user must have installed. I
went
with dynamic because it's the smaller and simpler of the two here.
For the rest: I'll drop the RPATH from the thunk libraries, make the host
thunk record its real library's SONAME (libfoo.so) instead of the build
path,
and add -L /usr/x86_64-linux-gnu/ to the documented command.
