[fpc-pascal] Freepascal on OSX 10.9 Mavericks $LINKLIB gcc broken

[Jonas Maebe]

On 10 Mar 2014, at 19:07, md at 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