Show quoted text 7 lines
Unfortunately, your suggestion while appreciated does not work.
For example, the actual function "__divdi3" actually lives in
/usr/lib/system/libcompiler_rt.dylib
This library does not exist on Snow Leopard. But it does exist on
Mavericks. (I do not have Lion/Mtn Lion available)
It's the equivalent of libgcc for LLVM.
Show quoted text 11 lines
{$LINKLIB gcc_s} does not work -> Library NOT found by FPC compiler/linker
{$LINKLIB compiler_rt} does not work -> Library NOT found by FPC
compiler/linker
{$LINKLIB /usr/lib/system/libcompiler_rt.dylib} does not work ->
Library NOT found by FPC compiler/linker
{$LINKLIB /usr/lib/libgcc_s.1.dylib} does not work -> Library NOT
found by FPC compiler/linker
I also tried using:
{$LIBRARYPATH /usr/lib/system}
{$LINKLIB compiler_rt}
I've looked into it. In short:
* make sure you are using FPC 2.6.2 or later.
* do *not* add any linklib statement
* use the compiler command line parameter -WM10.6 (if you want to target minimally Mac OS X 10.6) ... -WM10.9 (if you want to target OS X 10.9)
In long:
In 10.6 and later those symbols are part of the system library (libSystem, which is the same as libc). That means that if you target 10.6 or later, you don't need to explicitly link against libgcc anymore. However, the linker will only get those symbols from libc/libSystem if you target 10.6 or later, because it knows that they are not available on OS versions.
Npw, FPC's default Mac OS X target for Intel is either 10.4 (for i386) or 10.5 (for x86-64). You did not have problems when compiling under 10.6, because
a) under that OS version, gcc was still installed as part of the developer tools
b) this copy of gcc came with a statically linkable version of libgcc (/usr/lib/gcc/powerpc-apple-darwin10/VERSION/libgcc.a) c) FPC's installer asks gcc for the path to this libgcc.a and adds a library search path for it to the default config file
As a result, adding {$linklib gcc} worked to resolve the symbols.
It doesn't work under 10.9, because there is no global gcc installation anymore, and hence no accompanying libgcc.a anywhere.
Now, since Mac OS X 10.4 you can also dynamically link to libgcc instead of statically (the libgcc_s file). Under 10.4 and 10.5, this file still contained the helpers. That's why you have the following files in /usr/lib:
lrwxr-xr-x 1 root wheel 17 Oct 22 22:20 /usr/lib/libgcc_s.1.dylib@ -> libSystem.B.dylib
-rwxr-xr-x 1 root wheel 30984 Oct 23 21:09 /usr/lib/libgcc_s.10.5.dylib* lrwxr-xr-x 1 root wheel 19 Oct 23 21:09
/usr/lib/libgcc_s.10.4.dylib@ -> libgcc_s.10.5.dylib
The latter two are compatibility files for programs that were previously compiled with Mac OS X 10.4 or 10.5 as target. On those systems (and in those SDKs), libgcc_s.dylib was a symbolic link to libgcc_s.10.4.dylib resp. libgcc_s.10.5.dylib). As a result, programs compiled against those SDKs and linking to libgcc_s.dylib, would record libgcc_s.10.4.dylib resp. libgcc_s.10.5.dylib as the real library name in the binary, and will still work even though there's no libgcc_s.dylib anymore.
This means that you can still explicitly link your programs against them by adding {$linklib gcc_s.10.5} to your program. Unless you still want to support 10.5 or 10.4, using -WM10.6 or higher is probably better though (this parameter tells the compiler/linker that you targeting Mac OS X 10.6 and later, and hence the required symbols will be taken from libSystem).
Jonas
