LD_PRELOAD cannot be preloaded, possible regression with #4312

[gamesh411]

Describe the bug
On Ubuntu-24.04, when analyzing bitcoin v0.20.1, the logging phase fails.

CodeChecker version
master a6663b3

To Reproduce

# Fresh build of CodeChecker on master
git clone https://github.com/Ericsson/codechecker.git
cd codechecker
make venv package
source venv
export PATH="$PWD/build/CodeChecker/bin:$PATH"
cd ..
# Clone and log bitcoin project
git clone https://github.com/bitcoin/bitcoin.git -b v0.20.1
cd bitcoin
./autogen.sh && ./configure --disable-wallet --disable-static --disable-tests --without-gui
CodeChecker log -b 'make -j' -o compile_commands.json

Results in this error for all TUs:

CXX      lib/libunivalue_la-univalue_get.lo
ERROR: ld.so: object 'ldlogger.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Expected behaviour
I expect the log to produce a compilation database, but it is empty.

Desktop (please complete the following information)

• OS: WSL Ubuntu-24.04
• Browser: not relevant
• Version: not relevant

Additional context
I see that the issue came up in #3858, and I suspect that the regression to this error happened #4312.
I think the change should not just be reverted, but instead, the machine architecture of the TU analyzed should be added to LD_LIBRARY_PATH env variable of the compiler invocation to be logged.

[gamesh411]

I have tested with the latest master version (already CMake-based) Bitcoin project, and there is no mention of it overriding the LD_LIBRARY_PATH. The issue still holds.
IMO we need this #3919, but with the modification that ensures we also support a different-architecture binary than the host OS.

Right now, I see 2 ways of doing this:

1. we detect the architecture of the compiler we use for logging
2. blindly pass all the shared objects to the binary by adding all of them (maybe multiple absolute path entries for LD_PRELOAD, or just a relative path, and adding all the machine-specific directories to LD_PRELOAD_PATH)

[dkrupp]

The problem with the solution in #3919 (which was reverted and fixed in #4314) was that it put the absolute path of the ldlogger.so into to the LD_LIBRARY_PATH. The 32bits version of the ldlogger.so was used on a 32bits host, and the 64bits version on a 64 bits host. Unfortunately this is not correct, as not the architecture type of the host which matters, but the architecture type of the gcc compiler that we logged. So a user reported that logging was not working correctly when he was logging a 32bits gcc on a 64 bits machine as the 64 bits ldlogger was loaded which could not be dynamically linked with the 32bits gcc.

The currently implemented strategy as of #4314 is the following:
The ldlogger.so is placed in
/opt/CodeChecker/ld_logger/lib/i386/ldlogger.so #32 bits
/opt/CodeChecker/ld_logger/lib/x86_64/ldlogger.so #64 bits

We set the LD_LIBRARY_PATH to the directory containing containing dir and the LD_PRELOAD env var to relative ldlogger.so
LD_LIBRARY_PATH=/opt/CodeChecker/ld_logger/lib
LD_PRELOAD=ldlogger.so

then the linux will automatically select the ld_logger/lib/i386 and the ld_logger/lib/x86_64 subdirectories based on the architecture of the logged gcc.

Has this behaviour changed on the newest linux ubunut 24? The current implementation works fine (according to my tests) on ubuntu 20,22, rhel 8,9.

[gamesh411]

I have created a draft for option 2 since it seemed like the simpler solution.
I have also tested it on Ubuntu24, and the multiple .so files that are possibly reachable due to all of them being added are not an issue, the logger works as expected, and if I remove only the relevant ldlogger.so (x86_64 for my machine), but kept the others, the log command correctly detected that I meet neither the ld-logger nor the intercept-build requirement.
I have also left in the old path, which just includes the lib folder.

PR here: #4394