I’m developing a small library which intercepts some library calls from a program installed via home-manager. My library works fine outside of nix, but it fails when trying to intercept calls from a program installed via home-manager. I figured that it is related to hardcoded library paths in my interceptor library.
lld shows
linux-vdso.so.1 (0x00007fff7a341000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007fb2f3b72000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb2f391c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb2f38f8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb2f3716000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb2f3637000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb2f3cac000)
What is the preferred approach here?
- Changing the paths in my binary doesnt seem very portable?
- Setting LD_LIBRARY_PATH seems also a hassle
- Are there linker settings which could help
- Or, should I “just” (no idea, how to do this) create a derivation for my program and install it via home-manager, too?
Any pointers are greatly appreciated. Cheers!
1 point
thanks. my understanding was that i would have to redo this every time my binary changes or nix package paths change. for the moment this seems quite laborious.
1 point
Yes, you would. It’s a tool commonly used to patch over paths in binaries that cannot be produced from source (aka. proprietary ) when packaging them in derivations.
1 point