0

I have a c++ shared library which as part of its normal behaviour fork()/execs() another executable containing some unstable legacy code. This executable is not useful other than with this library, so I'd like to avoid placing it in a PATH directory. I'd also like to be able to install multiple copies in various locations, so hard coded paths are not desirable. Is there anything equivalent to a RPATH that will allow exec() to find this executable? Alternatively, is it possible to query the rpath of a shared library from the library itself?

Edit: This post suggests the latter is possible. I'll leave this open in case anybody knows the answer to the asked question. Is there a way to inspect the current rpath on Linux?

Community
  • 1
  • 1
tgoodhart
  • 3,111
  • 26
  • 37
  • Hobbes, are you using autotools? – Fred Foo Mar 31 '11 at 19:54
  • larsmans: No autotools. Cmake. – tgoodhart Mar 31 '11 at 19:55
  • Ok. Doesn't matter very much. Autotools supports putting backend binaries in a directory `$prefix/libexec`, which is the traditional place for this stuff. Under the FHS it's `/usr/{local/}lib/PACKAGE`. That doesn't answer your question directly, but I know at least and Ubuntu advise against `RPATH`. – Fred Foo Mar 31 '11 at 19:59

2 Answers2

1

You can always use getenv to get the environment within the shared object, but is RPATH really what you want to use for that? Wouldn't it be better to have the shared object have some sort of configuration file in the user's home directory (or custom environment variable) that tells it which location to use run the external binary?

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • Custom environment variable isn't desirable because it would expose a pretty huge implementation detail. Configuration file is would be difficult because there's no guarantee as to where the executable will be located, and I'd like to support having multiple copies of the executable. I could write a config file as part of an RPM post install script, or something equivalent, although I'd really like the process to be transparent to any users of the library. – tgoodhart Mar 31 '11 at 19:51
0

I think the best way to do this is to set an environment variable and use execve() to run the binary. Presumably you could just set PATH and then execve() a shell that would use PATH to find a copy of the executable. The library equivalent would be to set LD_LIBRARY_PATH and execve() a binary that has this library as a dependency.

In either case, you are not changing the external environment, only manufacturing a modified copy that is used with execve().

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106