install_name_tool failing on 3rd party dylib

Hello,

A vendor recently updated their SDK and I'm trying to update my project to use the new dylib. I'm not able to use the dylib out of the box due to linking problems, so fired up install_name_tool to update the id to properly work in my situation (similar thing worked with their prior release.)

However, with this build I'm getting the error:

% install_name_tool -id @rpath/libblahblahblah.dylib libblahblahblah.dylib

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: fatal error: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): libblahblahblah.dylib (for architecture x86_64)

Google isn't returning much beyond explanations of the macho file layout. Is there a simple way to alter the dylib locally to address this? Is there something I can suggest the vendor does upstream?

Thanks, mike

Replies

What does the following command report for this library?

% vtool -show libblahblahblah.dylib

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • libxxxxxx.dylib (architecture x86_64): Load command 8       cmd LC_VERSION_MIN_MACOSX   cmdsize 16   version 10.9       sdk 12.0 Load command 9       cmd LC_SOURCE_VERSION   cmdsize 16   version 0.0 libxxxxxx.dylib (architecture arm64): Load command 9       cmd LC_BUILD_VERSION   cmdsize 32  platform MACOS     minos 11.0       sdk 12.0    ntools 1      tool LD   version 711.0 Load command 10       cmd LC_SOURCE_VERSION   cmdsize 16   version 0.0
Add a Comment

Strangely, I've found compiling the app with the unedited lib causes Xcode to alter the dylib in some way that I can then copy it out of the product and successfully run install_name_tool

-mike

Sadly, your vtool output is unreadable. On the plus side, it’s probably not necessary because:

I've found compiling the app with the unedited lib causes Xcode to alter the dylib in some way that I can then copy it out of the product and successfully run install_name_tool

Hmmm, that’s weird. Xcode generally doesn’t monkey with a dynamic library other than to sign it. If you sign the library from the command line, does that clear the issue?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Anyone here from Google: this happens when you try to manipulate rpaths on a bundle (MH_BUNDLE) rather than a shared library (MH_DYLIB).

Bundles sometimes have the same file extension as shared libraries (.dylib) but you can tell the difference with the file command:

% file x.dylib
x.dylib: Mach-O 64-bit dynamically linked shared library arm64
% file x.so
x.so: Mach-O 64-bit bundle arm64

The linker will add an rpath to a bundle no problem, but install_name_tool can't manipulate it.

this happens when you try to manipulate rpaths on a bundle

That’s not my experience:

% file Test701672.bundle/Contents/MacOS/Test701672                              
Test701672.bundle/Contents/MacOS/Test701672: Mach-O 64-bit bundle x86_64
% otool -l Test701672.bundle/Contents/MacOS/Test701672 | grep -B 1 -A 2 LC_RPATH
% install_name_tool -add_rpath /foo/bar Test701672.bundle/Contents/MacOS/Test701672
/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: Test701672.bundle/Contents/MacOS/Test701672
% otool -l Test701672.bundle/Contents/MacOS/Test701672 | grep -B 1 -A 2 LC_RPATH
Load command 18
          cmd LC_RPATH
      cmdsize 24
         path /foo/bar (offset 12)
% install_name_tool -rpath /foo/bar /bar/baz Test701672.bundle/Contents/MacOS/Test701672
/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: Test701672.bundle/Contents/MacOS/Test701672
% otool -l Test701672.bundle/Contents/MacOS/Test701672 | grep -B 1 -A 2 LC_RPATH        
Load command 18
          cmd LC_RPATH
      cmdsize 24
         path /bar/baz (offset 12)

I’m using macOS 13.2.1 with Xcode 14.2.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"