5

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?

Alex Reynolds
  • 95,983
  • 54
  • 240
  • 345
  • Something appears to be broken with 10.6 support and the build of `gcc` available through MacPorts. I can't get much support through the MacPorts folks, so I've dropped 10.6 support for now (e.g., compiling with the `-mmacosx-version-min=10.7` flag setting). – Alex Reynolds Dec 30 '13 at 09:23
  • install_name_tool displays an error if there is not enought room for the new library path (at least on 10.9) – Paolo Feb 11 '14 at 12:36

0 Answers0