install_name_tool -change fails silently and ignores -headerpad_max_install_names flag

Question

I have a command-line executable that includes links to dylibs that — when distributed — will not be at the stated location returned by otool -L.

For instance, given a binary called 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-installation script that tries to use install_name_tool -change to fix this, so that foo links to the dylib in its 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 silently. When I run 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 fat binaries and tried adding the -headerpad_max_install_names compilation flag to the 32-bit Makefile. This did not fix the problem, in that install_name_tool -change still fails silently.

I read that -headerpad_max_install_names does nothing on 64-bit platforms, but I added it to the 64-bit Makefile anyway. Predictably, this did not fix the problem, either.

How do I fix my compilation procedure, so that I can ultimately change the path of the linked dylib with install_name_tool?