[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260311152049.GN3520958@port70.net>
Date: Wed, 11 Mar 2026 16:20:49 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Jon Chesterfield <jonathanchesterfield@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Path for deploying clang on glibc systems
* Jon Chesterfield <jonathanchesterfield@...il.com> [2026-03-11 12:11:07 +0000]:
> Some years ago I tried to ship llvm dynamically linked against musl and
> failed - couldn't install the musl loader globally, interp path wanted an
> absolute string and I don't know the target filesystem layout.
this is a limitation of elf on linux.
the kernel loads ld.so from abs path in PT_INTERP of the exe.
workarounds:
(1) hijack the fs so ld.so path is right e.g. with namespaces
(can use a complex container runtime, but just a bind mounted
ld.so can be enough for musl, however fork+exec may not use
the right namespace when e.g. system runs /bin/sh)
(2) hijack the elf entry so dynlinking is done with right ld.so
(either exec ./ld.so binary or modify a static entry code, may
not work well with various binary instrumentation tools)
>
> Dynamic linking of libLLVM.so and libclang-cpp.so has a drastic impact on
> toolchain size so dropping that is a tough sell.
>
> It seems obvious that musl could be statically linked into the main
> executable, do the dynlib setup work as usual, then branch to the
> executable main to get a self contained path independent distribution.
>
> I haven't seen this done though. Am I unobservant in and such a trick is
> already available, is it a case of patches considered, or is this just a
> dumb thing I shouldn't do?
i think for a toolchain (2) with wrapper script should work:
exec path/ld.so path/$(basename "$0") "$@"
has a tiny wrapper overhead and may need --path ldpath setting.
issues: if the binary tries to self re-exec, argv[0] is the
basename not ld.so. tools like gdb, valgrind, qemu, ldd,...
don't work on a wrapper script, needs manual tool ./ld.so binary,
may not like that the main exe is loaded by ld.so, not the kernel.
(should not be a big deal for a toolchain)
using a static linking entrypoint is a lot more involved,
requires either whole-libc or runtime loaded ld.so, the latter
is https://www.openwall.com/lists/musl/2020/03/29/9
for (1) a wrapper would unshare+bind mount an abs path like /lib.
if the toolchain does not exec external binaries then this could
work too, and then the kernel loads the ld.so+exe and no argv[0]
manipulation takes place.
>
> Context is people wanting to run on weird kernel configurations and I don't
> want exposure to glibc bugs circa two decades ago.
>
> Thanks all!
>
> Jon
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
