Q:

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

A:

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

