The Holy Grail of Linux Binary Compatibility: Musl and Dlopen

Re:The Holy Grail of Linux Binary Compatibility: Musl and Dl... by toast0 on Monday January 26, 2026 @11:33AM (#46767746)

> But I'm always a bit sceptical about such approaches. They are not universal. You still need glibc/musl to be the same on the target system. Also, if you compile againt new glibc version, but try to run on old glibc version, it might not work.

Why would you include most of your dynamic libraries but not your libc?

You could still run into problems if you (or your libraries) want to use syscalls that weren't available on older kernels or whatever.

[ Parent | on HN ]

Re:The Holy Grail of Linux Binary Compatibility: Musl and Dl... by mdavid626 on Monday January 26, 2026 @11:44AM (#46767883)

You can include it, but

- either you use chroot, proot or similar to make /lib path contain your executable’s loader

- or you hardcode different loader path into your executable

Both are difficult for an end user.

[ Parent | on HN ]

Re:The Holy Grail of Linux Binary Compatibility: Musl and Dl... by toast0 on Monday January 26, 2026 @11:58AM (#46768104)

This isn't that hard. Your executable should be a statically linked stub loader with an awful lot of data, the stub loader dynamically links your real executable from the data and runs it.

[ Parent | on HN ]

Re:The Holy Grail of Linux Binary Compatibility: Musl and Dl... by fc417fc802 on Monday January 26, 2026 @01:03PM (#46769167)

To add to this, in case of any remaining confusion. You can implement your own execve in userspace. [0] But the kernel's execve is a piece of machinery that invokes the loader so obviously it follows that you're free to make any changes you'd like to the overall process.

Bonus points if you add compression or encryption and manage to trip a virus scanner or three. [1]

[0] https://grugq.github.io/docs/ul_exec.txt

[1] https://blackhat.com/presentations/bh-usa-07/Yason/Whitepape...

[ Parent | on HN ]