0

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

user962460
  • 153
  • 1
  • 8
  • 1
    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 Apr 08 '20 at 06:48
  • 1
    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 https://stackoverflow.com/questions/60497896/self-modifying-code-on-darwin-10-15-resulting-in-malformed-mach-o-image/60505259#60505259 `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 Apr 08 '20 at 07:53
  • I removed the LC_LOAD_DYLIB as per the post but when I do otool -L again, I get truncated or malformed object (load command 2 fileoff field plus filesize field in LC_SEGMENT_64 extends past the end of the file) ./jtool2 -L produces /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) and my xcode fails to build ;( – user962460 Apr 08 '20 at 09:15
  • 1
    could you include all load commands for both dylibs for comparison? The more information you provide the bigger chance someone can help. – Kamil.S Apr 08 '20 at 10:17
  • The only LC_LOAD_DYLIB that I excluded was my own dylib – user962460 Apr 09 '20 at 06:10
  • I just updated my answer – user962460 Apr 09 '20 at 09:20
  • 1
    you need to use a relative path not an absolute path – Kamil.S Apr 09 '20 at 09:35
  • How would I go about changing it both in the cross compiled dylib and in my project settings? – user962460 Apr 09 '20 at 09:36
  • 1
    https://blog.krzyzanowskim.com/2018/12/05/rpath-what/ – Kamil.S Apr 09 '20 at 09:44
  • Thanks, will look into it – user962460 Apr 09 '20 at 10:01
  • Alright that did the job, many thanks, wish I could give you more rep points :) – user962460 Apr 10 '20 at 11:07
  • please post solution that solve your problem as an answer for future readers. – Kamil.S Apr 10 '20 at 12:00

1 Answers1

0

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

user962460
  • 153
  • 1
  • 8
  • Check out the `copy_dylibs.py` script in this [git repo](https://github.com/trojanfoe/xcodedevtools) which should do all the `install_name_tool` shenanigans for you. – trojanfoe Apr 12 '20 at 08:13