A non NixOS linux binary (matlab) requires libGL.so.1 twice?

Help
1

I’m having trouble running a certain binary of matlab 2022a, here’s the output of ldd:

(ins)matlab-shell-chrootenv:doron@ZENIX:~/downloads/software/matlab/download/matlab_R2022a_glnxa64$ ldd ./bin/glnxa64/MATLABWindow  | grep libGL
        libGL.so.1 => not found
        libGL.so.1 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGL.so.1 (0x00007f920723e000)
        libGLdispatch.so.0 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGLdispatch.so.0 (0x00007f92065c6000)
        libGLX.so.0 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGLX.so.0 (0x00007f9206591000)

Why would a binary require libGL.so.1 twice? How can I overcome that?

Any ideas would be welcome!

1 Like
2

Wild guess: Hardcoded path in matlab or a path not properly replaced by patchelf…

A quick workaround may be LD_PRELOAD=/nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGL.so.1 ./bin/glnxa64/MATLABWindow

1 Like
3

Might be the libGL.so from a transitive dependency that’s in regular FHS.
I wouldn’t trust ldd especially not when it’s the ldd from /usr/bin. I’m pretty sure that one is sometimes printing incorrect results from FHS when something with the RUNPATH isn’t quite right.
Better cross check with the ldd from elfutils.
I’ve had more luck with readelf -d or via LD_DEBUG=libs.

2 Likes