I have a command line executable that includes dylib links that, when distributed, will not be at the specified location returned by otool -L .
For example, given the binary code foo :
$ otool -L foo /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.18.0) ...
In my installer, I have a post-install script that tries to use install_name_tool -change to fix this, so that foo refers to dylib in a new location.
For instance:
$ sudo install_name_tool -change /opt/local/lib/libgcc/libstdc++.6.dylib /somewhere/else/more/sensible/libstdc++.6.dylib foo
But this change is ignored and fails. When I ran otool -L again:
$ otool -L foo /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.18.0) ...
Nothing changed.
I am compiling complete binaries and trying to add the -headerpad_max_install_names flag to the 32-bit Makefile. This did not install_name_tool -change problem, as install_name_tool -change still fails.
I read that -headerpad_max_install_names does nothing on 64-bit platforms, but I added it to the 64-bit Makefile. As expected, this also did not fix the problem.
How to fix my compilation procedure so that I can eventually change the path of the associated dylib using install_name_tool ?
source share