[Feat] Improve library discovery (libpython) when running inside a Conda environment

[oswaldblockdev]

Problem
I installed cargo-afl and cargo-test-fuzz inside a Conda environment (Python 3.13). Running cargo test-fuzz fails with error while loading shared libraries: libpython3.13.so.1.0.

afl-fuzz is dynamically linked to Conda's python lib, but Conda doesn't set LD_LIBRARY_PATH by default. So I need to manually set LD_LIBRARY_PATH as the workaound:

export LD_LIBRARY_PATH=$CONDA_PREFIX/lib

suggestion
Could afl.rs either:

• Attempt to static link libpython?
• Automatically detect $CONDA_PREFIX and augment the library search path when invoking afl-fuzz?

[smoelius]

I'd like to propose a third option. Please tell me if you think it does not make sense.

• Automatically detect $CONDA_PREFIX and augment the library search path when invoking afl-fuzz?

What if, following a failed invocation of afl-fuzz, cargo-afl checks for the CONDA_PREFIX and LD_LIBRARY_PATH environment variables. If it the former is set and the latter is not, cargo-afl could suggest to set LD_LIBRARY_PATH.

The change would go around here:

afl.rs/cargo-afl/src/main.rs

Line 233 in 57c6820

if tool == "afl-fuzz" && !status.success() {

Do you think that could work?

[oswaldblockdev]

Sorry for the delay. I’ve done some digging into the codebase.

It turns out that AFL++'s GNUmakefile uses python3-config, which is being overridden by Conda's version during the build process. I agree with the proposed fix. I don't necessarily view AFL's Python handling as a bug, as it actually makes testing against different Python versions easier.

https://github.com/AFLplusplus/AFLplusplus/blob/afbcb07e7602791390adfc63932efcd14d39bab8/GNUmakefile#L225-L231

[smoelius]

@oswaldblockdev Not sure if you noticed, but I proposed a fix in #692. If you could please take a look, when you get a chance.