Overriding installation path in shared libraries built with automake/libtool during build for testing when DYLD_LIBRARY_PATH cannot be used

[Diab Jerius]

I recently posted a question about this to stackoverflow:

https://stackoverflow.com/questions/44979427/overriding-installation-path-in-shared-libraries-built-with-automake-libtool-dur

Rather than repeat the posting here, I'll just post the synopsis of the problem:

Starting with OS X 10.11, when System Integrity Protection is on,
dynamic linker environment variables are not passed to subprocesses.
In a project which produces two libraries, one dependent upon the
other, test code (a shell wrapper around an executable) linked against
the libraries fails to run, as the installation path is hardwired into
the libraries, the libraries have yet to be installed, and the dynamic
linker will try to find them using the hardwired paths in the
libraries. Because DYLD_LIBRARY_PATH is not passed along to
subprocesses (e.g., the executable run by the test wrapper script) it
is not possible to direct the linker to look elsewhere.


I posted a solution which uses the OS X install_name_tool to modify
the hardwired dependency information in the dependent library so that
testing can proceed, and restores it upon installation.

It's a bit of a kludge. Would anyone have a more elegant solution?

Thanks,

Diab