On 7/10/2026 10:05 PM, Ziyang Zhang wrote: > 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. >
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. > 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. > Regards, Pierrick
