install_name_tool failing on 3rd party dylib

Developer Tools & Services General
mike woodworth OP
Created Mar ’22
Replies 5
Boosts 0
Views 3.2k
Participants 3

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  5
Boosts  0
Views  3.2k
Participants  3
DTS Engineer OP
Apple
Mar ’22

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"

0
mike woodworth OP
Mar ’22

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

0
DTS Engineer OP
Apple
Mar ’22

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"

0
mansourmoufid OP
Apr ’23

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.

0
DTS Engineer OP
Apple
Apr ’23

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"

0
install_name_tool failing on 3rd party dylib
First post date Last post date
 
 
Q