On 10 Mar 2014, at 19:07, m...@rpzdesign.com wrote:
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.
{$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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
