Handling "dyld: lazy symbol binding failed: Symbol not found" error when nm does not find symbol

Question

I have a fat (32- and 64-bit) Intel binary called myBinary that fails to run on another workstation running Mac OS X 10.8.2:

$ myBinary
dyld: lazy symbol binding failed: Symbol not found: __ZNSt8__detail15_List_node_base7_M_hookEPS0_
  Referenced from: /usr/local/bin/myBinary
  Expected in: /usr/lib/libstdc++.6.dylib

dyld: Symbol not found: __ZNSt8__detail15_List_node_base7_M_hookEPS0_
  Referenced from: /usr/local/bin/myBinary
  Expected in: /usr/lib/libstdc++.6.dylib

Trace/BPT trap: 5

I compiled it from a Mac OS X 10.8.2 workstation running GCC 4.7.2:

$ gcc --version
gcc (MacPorts gcc47 4.7.2_2+universal) 4.7.2

I ran nm and the symbol is undefined:

$ nm /usr/local/bin/myBinary | grep __ZNSt8__detail15_List_node_base7_M_hookEPS0_
     U __ZNSt8__detail15_List_node_base7_M_hookEPS0_

What did I miss or do wrong when compiling myBinary? I'm not sure what I can do about a missing symbol in /usr/lib/libstdc++.6.dylib — should I have statically compiled the C++ library into myBinary?

Solution 1

yeah you have 2 options, either not use libraries that the customer won't have... (you can provide them as a dyld or framework.)

or just statically link the library... this will actually end up being smaller in memory and disk space if your package is only one process, because you can strip symbols that you don't use.

Solution 2

Each C++ compiler has its own implementation of Standard C++ Library. Since you're using external compiler (GCC 4.7) its library is not available among standard installations of Mac OS X.

Your only options is to either bundle the library within your app or statically link it.

To bundle the library with the app:

1. Update install name of the library using install_name_tool

2. Ensure your app will find it when needed

E.g. you can put the dylib into .app/Contents/Frameworks, set its install name to @rpath and compile you app with the -rpath @executable_path/../Frameworks.

Comments

[Ken Thomases]

Or use the system tool chain and the system C++ library.

[Grady Player]

I used this technique to ensure that I had the same c++ lib on 10.5-8... when you are compiling your own or using a package you will want to make sure that the lib will run on all of the versions you are interested in... which can be problematic if you are supporting 10.5 and 32 bit. I think it is absolutely possible though.

[Grady Player]

the concerns about compatibility are the same for shipping a dyld as statically linking.