Mike Melanson wrote: > Sounds like a useful possible solution. However, what if the primary > functionality actually resides in a shared library itself?
As shown by ldd on the shared library? Those will be loaded using LD_LIBRARY_PATH so in that case you don't need the complicated wrapper for libc using ld.so but just the simple one that only sets the environment variable for the dynamic loader to follow. Unless the shared library is using rpath. In which case it will use the compiled in path first and only if that fails will it fall back to using LD_LIBRARY_PATH and if that fails fall back to using whatever is configured for the system in /etc/ld.so.conf. (I do not like rpath because it freezes the configuration into an inflexible state.) > This is a proprietary plugin that another program is expected to > load and call. Is there some sort of wrapper trick for that, or is > that up to the communication between the app and the plugin? Everything depends upon how the application is loading the shared library. If it done by the linker then ld.so will load it and LD_LIBRARY_PATH should work to find it. If the application is dynamically loading a specific file from the filesystem then you are stuck with whatever the application allows you to adjust. All of this is assuming that I did not get some of this wrong. Bob
