0

I am running a program with a set of custom libraries as follows:

/path/to/my/ld-linux-x86-64.so.2 --library-path /path/to/my/libs /path/to/my/executable

This works great for most of the programs I am trying to run, but it doesn't seem to work for one which spawns subprocesses. I'm pretty sure the subprocesses are being spawned with standard glibc execve. The subprocess is failing with a library error which appears to be caused by it not being executed properly. The program works with LD_LIBRARY_PATH set to the a directory containing all of the libraries except libc in a distroless Docker container, so I am pretty sure that I have all of the libraries correct.

I also tried using both setting LD_LIBRARY_PATH and invoking with ld-linux-x86-64.so.2, but that doesn't work either.

I think the problem is that the subprocess is reverting to the system /lib64/ld-linux-x86-64.so.2.

For context, I have a binary (and a second binary which the first invokes as a subprocess) that I didn't build that I want to run on various systems with different sets of dynamic libraries installed. Using LD_LIBRARY_PATH and providing all libraries except libc works for most environments, except for one with a really old glibc installed.

Ian
  • 348
  • 1
  • 2
  • 11

1 Answers1

1

I think the problem is that the subprocess is reverting to the system /lib64/ld-linux-x86-64.so.2.

That is what one should expect to happen if the execve argument is /path/to/subprocess or subprocess.

If you want the subprocess to use explicit loader invocation /path/to/my/ld-linux-x86-64.so.2 --library-path /path/to/my/libs /path/to/subprocess, then you must arrange for execve arguments to be exactly that.

This is why using patchelf or other solutions from this answer is generally a better approach.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362