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!

  • drre@feddit.deOP
    1·
    1 year ago

    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.

    • ck_
      1·
      1 year ago

      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.

      • drre@feddit.deOP
        1·
        1 year ago

        okay, in that scenario this makes sense. I’ll try to get into building derivations for my own stuff then. thanks a lot