Question

I am linking a binary which imports a symbol defined in two dependent dylibs, and I can’t make ld to pick the correct one.

The symbol is _init_process and it’s defined both in libSystem.dylib (added by ld implicitly) and libida.dylib (our library). I want ld to pick libida but I can’t make it work.

Here’s the final linker command line:

/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld -dynamic -dylib
-dylib_compatibility_version 1.0 -dylib_current_version 1.0 -arch
i386 -macosx_version_min 10.5 -macosx_version_min 10.5
-single_module -weak_reference_mismatches non-weak -w -o
../../bin/x86_mac_gcc/plugins/python.pmc -ldylib1.10.5.o
-L../../bin/x86_mac_gcc/
-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin10/4.2.1
-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/usr/lib/gcc/i686-apple-darwin10/4.2.1
-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1
-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../..
-v -lpthread ../../lib/x86_mac_gcc_32/libiconv.2.2.0.dylib
obj/x86_mac_gcc_32/python.o32 obj/x86_mac_gcc_32/idaapi.o32 -lida
-install_name python.pmc -lpython2.6 -ldl -why_load
-search_paths_first -t -lstdc++ -lgcc_s.10.5 -lgcc -lSystem

As you can see, -lida comes before -lSystem, so I would expect ld to pick libida.dylib first, but it’s not happening:

dlopen(/home/test/build/bin/x86_mac_gcc/plugins/python.pmc): dlopen(/home/test/build/bin/x86_mac_gcc/plugins/python.pmc, 2): Symbol not found: _init_process
  Referenced from: /home/test/build/bin/x86_mac_gcc/plugins/python.pmc
  Expected in: /usr/lib/libSystem.B.dylib
 in /home/test/build/bin/x86_mac_gcc/plugins/python.pmc
/home/test/build/bin/x86_mac_gcc/plugins/python.pmc: can't load file

Debug output from the linker:

Library search paths:
    ../../bin/x86_mac_gcc/
    /Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin10/4.2.1
    /Developer/SDKs/MacOSX10.5.sdk/usr/lib
    /usr/lib/gcc/i686-apple-darwin10/4.2.1
    /usr/lib/gcc/i686-apple-darwin10/4.2.1
    /Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin10/4.2.1
    /Developer/SDKs/MacOSX10.5.sdk/usr/lib
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/dylib1.10.5.o
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpthread.dylib
../../lib/x86_mac_gcc_32/libiconv.2.2.0.dylib
obj/x86_mac_gcc_32/python.o32
obj/x86_mac_gcc_32/idaapi.o32
../../bin/x86_mac_gcc//libida.dylib
/usr/lib/libpython2.6.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libdl.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin10/4.2.1/libstdc++.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libgcc_s.10.5.dylib
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libgcc.a
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.dylib
/usr/lib/system/libmathCommon.A.dylib

Answer 1

Solved it. The culprit was -lpthread – libpthread is a symlink to libSystem:

$ ls -la /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpthread.dylib
lrwxr-xr-x  1 root  wheel  15 Nov  9  2011 /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libpthread.dylib -> libSystem.dylib

After moving it after -lida, everything works as expected.