Search code examples
swiftmacosframeworksdylibmach-o

dyld: lazy symbol binding failed when trying to static link a dylib in swift


I built a dylib file using fpcupdeluxe in freepascal with just a single cdecl _test function exposed on both 1) MacOS and 2) Debian (cross compiled to x86_64 darwin)

I tried calling dylib using 1) dlopen 2) Bridging header 3) Framework

The dylib compiled on MacOS worked with all 3 methods. However when I replaced that dylib with the one I crosscompiled on debian, only dlopen seems to work, the other 2 methods using bridging header and framework gave me this error: dyld: lazy symbol binding failed: Symbol not found: _test

I did an nm -gU on both dylib and only the relative virtual address of the _test function is different, what can I do to investigate the cause of this and solve it?

otool -L for the

Non-working

XXXXX.dylib: /home/wire/fpcupdeluxe/projects/XXXXX.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1252.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1253.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

Working

/Users/wire/XXXXX.dylib: /Users/wire/XXXXX.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

Where XXXXX is my library name, I have also noticed the path is different for the working and non working one. In the non-working one, my dylib points to the directory on my linux machine that is not supposed to be present on the mac. I have also tried to cross compile on windows and the path was in C:\ and the error was image not found, do I have to change that path? I'm new to MacOS programming


Solution

  • Thanks to Kamil.S, I found the solution that I just had to run install_name_tool -id @rpath/ to set it to a relative path since unlike in windows all paths to dynamic libraries are stored in the mach-o structure itself