On 2025-04-15 11:34, Helmut Grohne wrote:
>
> I can also tell you that running a kfreebsd-amd64 ELF executable on a
> Linux amd64 kernel works "too well". The Linux kernel cannot tell these
> architectures apart from the ELF header and happily runs it. As the
> syscall ABI is completely different, you end up doing stuff you never
> wanted such as resetting your system clock before the program quickly
> fails.
>
> Loading shared libraries is a different beast as it is done by glibc.
> There the story looks different. If you attempt to load incompatible
> libraries you tend to see the error "wrong ELF class: ..." from
> dlerror() after having tried loading it with dlopen. Not so, if your
> architectures are too similar. For instance, attempting to load an armel
> library into an armhf executable, I got "cannot open shared object file:
> No such file or directory" (and note that it successfully opened but not
> mapped the file).
Per Simon's other post, none of that is relevant for his proposed option 2,
which boils down to dlopen("libvulkan_*.so", ...). If that could end up opening
a variant from a wrong search path, it'd break lots of other things anyway.
In summary, Simon's option 2 seems like the clear winner. As he pointed out, it
matches what's already being done for libEGL_mesa.so.0 shipped in libegl-mesa0,
with no known issues.
--
Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
