2

I'm trying to put an executable together to send to another computer. otool -L "exec_name" returns:

/usr/local/opt/glfw/lib/libglfw.3.dylib (compatibility version 3.0.0, current version 3.3.0)

trying to change it to my executable directory:

install_name_tool -id @executable_path/libglfw.3.3.dylib libglfw.3.3.dylib

it gives a warning:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: libglfw.3.3.dylib (for architecture x86_64)

but nothing changes, otool -L still shows:

/usr/local/opt/glfw/lib/libglfw.3.dylib (compatibility version 3.0.0, current version 3.3.0)

I also tried

install_name_tool -id @executable_path/libglfw.3.3.dylib libglfw.3.dylib

This gives an error:

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: libglfw.3.dylib (No such file or directory)

Cannot understand why it would not change the path...

user1298416
  • 341
  • 4
  • 11

1 Answers1

2

Two issues:

  1. It's @executable_path, not @executive_path.

  2. You need to change the install name both in the library and the binary that links against it:

    install_name_tool -id @executable_path/libglfw.3.3.dylib libglfw.3.3.dylib
install_name_tool -change /usr/local/opt/glfw/lib/libglfw.3.dylib @executable_path/libglfw.3.3.dylib [exec_name]

For a deeper explanation of how install names work, see this answer of mine.

Siguza
  • 21,155
  • 6
  • 52
  • 89
  • Wow, thanks for the answer and for the link, it it extremely helpful. I still don't understand why xcode linked with /usr/local/opt/glfw/lib/libglfw.3.dylib when I explicitly told it to link with the one from Cellar: /usr/local/Cellar/glfw/3.3.4/lib/libglfw.3.3.dylib . I understand /usr/local/opt/glfw/lib/libglfw.3.dylib is an alias that points to the /usr/local/Cellar/glfw/3.3.4/lib/libglfw.3.3.dylib, still not sure why would not take the one I wanted.But this is another question. – user1298416 Jun 21 '21 at 13:28
  • Because it doesn't just use the path you provide. It reads the file at that path, parses its load commands, and uses the install name embedded in that binary. So symbolic links change absolutely nothing. – Siguza Jun 21 '21 at 13:34
  • /usr/local/Cellar/glfw/3.3.4/lib/libglfw.3.3.dylib has /usr/local/opt/glfw/lib/libglfw.3.dylib embedded in it, correct? – user1298416 Jun 21 '21 at 13:48
  • That would be the logical conclusion, yes. – Siguza Jun 21 '21 at 13:52
  • Unfortunately after changing the name: @rpath/libglfw.3.3.dylib (compatibility version 3.0.0, current version 3.3.0) (I did rpath for consistency with other libraries), I started to get the following error: "Could not launch “AppName” Domain: IDEDebugSessionErrorDomain Code: 3 Failure Reason: “AppName” failed to launch or exited before the debugger could attach to it. Please verify that “AppName” has a valid code signature that permits it to be launched on “My Mac”. Refer to crash logs and system logs to for more diagnostic information. – user1298416 Jun 21 '21 at 14:02
  • User Info: { DVTRadarComponentKey = 855031; RawUnderlyingErrorMessage = "Bad executable (or shared library)"; }" – user1298416 Jun 21 '21 at 14:03