3

I'm trying to get a dylib working in my OSX project.

Ive been reading a few samples, this one specifically: Xcode 4 adding dylib

But I still cannot get it to work.

Here are the steps I have performed:

  1. Copied the testing.1.dylib to my Xcode projects folder.
  2. Ran sudo install_name_tool -id @executable_path/../Frameworks/testing.1.dylib testing.1.dylib

  3. Ran: otool -L testing.1.dylib and received the following:

    testing.1.dylib:
    @executable_path/../Frameworks/testing.1.dylib (compatibility version 2.0.0, current version 2.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

  4. Added the testing.1.dylib as a framework to the project. (Using the link bundle with library option).

  5. At this point when I compile the testing1.dylib does not get copied into the .App/Framework as I expected, so I manually create the Framework path and copy the testing.1.dylib to it: a) mkdir -p testing.app/Contents/Frameworks b) cp testing.1.dylib testing.app/Contents/Frameworks
  6. In Xcode I update the Runtime Search Paths for BOTH the Target and the Project to be: @executable_path/../Frameworks.

Now I copy the testing.app to a separate freshly installed machine and attempt to run it. Which I get the following error:

dyld: Library not loaded: /user/local/lib/testing1.dylib Referenced from: /Users/me/testing.app/MacOS/./testing Reason: image not found

What am I missing?

Notes: When running install_name_tool, I need to use sudo or I get the following errors:

install_name_tool: can't open input file: testing.1.dylib for writing (Permission denied) install_name_tool: can't lseek to offset: 0 in file: testing.1.dylib for writing (Bad file descriptor) install_name_tool: can't write new headers in file: testing.1.dylib (Bad file descriptor) install_name_tool: can't close written on input file: testing.1.dylib (Bad file descriptor)

Cœur
  • 37,241
  • 25
  • 195
  • 267
Kyle
  • 17,317
  • 32
  • 140
  • 246

2 Answers2

1

You shouldn't need to copy the library into the project.

You shouldn't need to use sudo to change the install name of a file you own. Do you not own the library file? Perhaps you did a "sudo make install" on some third-party project? Just don't install it and link to the one in the build directory. If you're building this library, then you should set its install name when it's built using command-line options to the link command.

It is expected that adding a library to a target causes it to be linked but doesn't automatically cause it to be copied. You can create a Copy Files build phase and add the library to that, too.

You don't need to set Runpath Search Paths unless you used an @rpath-based install name.

I suspect that Xcode is actually linking against the library that you copied from in step 1, rather than the copy you made and whose install name you then modified. What does the actual link command from the build transcript say? From where did you copy the library in step 1? If it was from /usr/lib or /usr/local/lib, then Xcode is probably linking against that.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
1

In the "XCode 4 adding dylib" question that you referenced, the answer appeared to be setting up a "Copy Files" build phase. This is pretty straightforward, since you already have the write executable path in your dylib. Now just go to your target settings > build phases > add build phase > copy files. Then drag the dylib from the Navigator sidebar to the files, and set the destination to Frameworks.

This should bundle the dylib to your app package contents, and the executable path within the dylib should point to the correct thing.

ejang
  • 3,982
  • 8
  • 44
  • 70