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

0
votes

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

1
swiftmacosframeworksdylibmach-o
You should diff the dylib binaries with tools like otool, jtool or if you prefer UI tools MachOExplorer or MachOTool to inspect and compare the Mach-O load commands. – Kamil.S
Good. I recommend removing the LC_LOAD_DYLIB for AppKit and Foundation from the dylib binary that your Debian cross compiler chain produces. You can achieve this using method I described in my answer here stackoverflow.com/questions/60497896/… jtool2 is available both on MacOS and Linux. By doing this you should at least learn if those extra frameworks are the culprit or it's something else – Kamil.S
could you include all load commands for both dylibs for comparison? The more information you provide the bigger chance someone can help. – Kamil.S
you need to use a relative path not an absolute path – Kamil.S
blog.krzyzanowskim.com/2018/12/05/rpath-what – Kamil.S

1 Answers

0
votes

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