I have the same exact problem as this question previously posted, where
/etc/ld.so.preload does not intercept the right architecture. A little background: I have compiled a shared object (64-bit) that is referenced in the
ld.so.preload file on any binary execution. The problem was that I was getting a
ERROR: ld.so: object '/usr/local/lib/mysharedobject.so' from /etc/ld.so.preload cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. when executing 32-bit programs.
To fix the issue according to the answer in that question, I had to make two directories (
x86_64-linux-gnu, for example, in
/var/opt) and specify
/etc/ld.so.preload so the right library will be preloaded depending in program architecture.
So in that case, in Debian based systems,
/var/opt/$LIB/mysharedobject.so would expand to:
/var/opt/lib/i386-linux-gnu/mysharedobject.sofor 32-bit programs;
/var/opt/x86_64-linux-gnu/mysharedobject.sofor 64-bit programs.
However, after applying this, any binary I run (such as
ls) will output the following 'error':
ERROR: ld.so: object '/var/opt/$LIB/mysharedobject.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
As you can see, $LIB did not expand to anything. I have also set
/var/opt and ran
ldconfig to update the system with this libs, but with no success. What is the problem here?