MacOSX: which dynamic libraries linked by binary?

Question

I have not been able to figure out why my binary is not loading. It is a dylib loaded by MATLAB (MEX-file), and links to quite a few dylibs in different locations. MATLAB tells me it cannot load the MEX-file, but I cannot figure out which of its dependencies it cannot find.

Does anybody have any suggestions for how to debug something like this?

On Linux, ldd is the perfect tool to debug this problem. People keep saying that otool -L is the MacOS equivalent to the Linux ldd, but this is not true. ldd actually looks for the libraries, and tells you which ones can be found, and where they were found. otool -L only tells you what libraries are needed to link against. It does not effort to check to see if they are there. It doesn't even tell you where libraries are searched for when they use @rpath.

otool -l (lowercase L) gives you a dump of the "load commands", there you can see the LC_RPATH commands, which establish where @rpath libraries are searched for. But these have not been able to explain to me which dependency is not found.

Solution 1

Try setting these environment variables before running matlab:

export DYLD_PRINT_LIBRARIES=1
export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
export DYLD_PRINT_RPATHS=1

Run man dyld for more possibilities.

You can also set the variables for just the matlab command like this:

DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 DYLD_PRINT_RPATHS=1 matlab

Solution 2

Rob Mayoff's answer is a great solution when working with executables. If you find you need to check the runtime dependencies of a dylib, the following script my-ldd may be useful.

#!/usr/bin/env bash 

while getopts "r" OPTION; do
  case $OPTION in   
    r) export DYLD_PRINT_RPATHS=1;;
  esac
done
shift $((OPTIND-1))

cp `which true` .
DYLD_PRINT_LIBRARIES=1 \
DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 \
DYLD_INSERT_LIBRARIES=$1 \
./true
rm ./true

where a the script may be invoked as

my-ldd ./foo.dylib

or (with rpath attempts echo'd)

my-ldd -r ./foo.dylib

Comments

[0 _]

Also, for inspecting Linux binaries on a macOS, greadelf from MacPorts can be used, as well as nm: unix.stackexchange.com/a/418357/43390, also relevant to: stackoverflow.com/a/23698812/1959808.

[0 _]

When trying otool -L for a Linux executable, an error was raised "object is not a Mach-O file type.".

[Cris Luengo]

@Ioannis: Yes, otool is for macOS binaries, not Linux ones. The SO answer you link talks about otool -L, which I already mention in the question is not useful in this particular case. readelf and nm are useful to see what symbols are in the binary, and serve a similar purpose to otool with other flags. None of them attempt to replicate the ldd functionality.

[0 _]

Thank you for noting that none of readelf, nm, and otool operate similarly to how ldd does. This comment motivated me to read further, and the information I collected does not fit in a comment, so I posted it in an answer to a question that seems closer to what I was searching for: stackoverflow.com/a/67818921/1959808

[0 _]

I arrived to this thread while searching for analysis on macOS of ELF executables (compiled on Linux). My understanding is that this use case is related to the question here, which is phrased about dylib, so Mach-O analysis on macOS, and what for Mach-O on macOS is the closest thing to ldd for ELF on Linux. My purpose for commenting was informational, to provide pointers for others that might find this thread while searching for ELF analysis on macOS.

[0 _]

I thought I was using macOS's otool, but was actually using the otool that is part of MacPorts package the cctools (installed as /opt/local/bin/otool). Both variants raise an error when given an ELF file, with tiny differences in the error message: /opt/local/bin/otool -L file_name says "llvm-objdump: error: file_name': object is not a Mach-O file type.", whereas /usr/bin/otool -L says: "llvm-objdump: 'file_name': Object is not a Mach-O file type.".

[0 _]

My comment about otool was intended for the ELF case only. If otool supported ELF files, it might have sufficed for what I was trying to confirm (I was looking for some specific versioned symbols). I did not intend to suggest that otool is equivalent to ldd. As you have noted, in general, otool does not perform the kind of analysis that ldd does.

[0 _]

Above, I linked to the SO answer: stackoverflow.com/a/23698812/1959808 with the purpose of linking the two threads.

[Cris Luengo]

This is excellent, thank you so much! Matlab has a boot script that seems to not pass on environment variables to the executable, so I added these variables to the script. I also used DYLD_PRINT_TO_FILE.

[Cris Luengo]

Nice! What is the reason this needs a local copy of the true binary? I tried running /usr/bin/true in this way and it doesn't work.

[apmccartney]

I encountered the same issue. It's an enhanced security measure put in place by Apple. See this link for more discussion