[fpc-pascal] Linking using "external" on Mac OS X

[Jonas Maebe]

On 28 mrt 2007, at 21:46, Michalis Kamburelis wrote:

> I experience problems linking using "external" keyword on Mac OS X.  
> Program with declaration like
>
> procedure glVertex3f(x, y, z: Single); cdecl; external 'GL' name  
> 'glVertex3f';
>
> fails to compile with
>
> $ fpc external_decl.pas
> /usr/bin/ld: Undefined symbols:
> _glVertex3f
> Error: Error while linking
>
> (note the strange underscore at the beginning of reported  
> "_glVertex3f").

There's nothing strange about the underscore. On Mac OS X, all  
external C symbols have an automatically prepended underscore (just  
like on e.g. Dos/go32v2, for example). Whether or not this is done  
depends on the platform's conventions.

> Similar problems seem to arise with gtkglext unit under Mac OS X.  
> What's interesting is that the problems are gone if I add {$linklib  
> GL} (in case of glVertex3f example). So it seems to me that  under  
> Mac OS X
> 1. the name of the library specified after "external" keyword is  
> ignored
> 2. I have to link to libraries using {$linklib xxx} method

That's correct. I did this in the beginning because almost many  
library names used in the sources we distribute are wrong for Mac OS  
X, and didn't feel like cleaning those up everywhere. I never got  
around to actually changing all those names into symbolic constants  
which are properly defined based on the platform and then enabling  
parsing of the library names in external definitions for Mac OS X.  
It's a fairly large and annoying task (modify and then test as many  
platforms as possible to make sure you didn't accidentally break  
another platform in the process).

> This is what gtk2 unit uses, and it links OK with GTK library from  
> fink. Also construct like
> function sem_post(__sem:Pointer): LongInt; cdecl; external 'c' name  
> 'sem_post';
> works OK in FPC's RTL, I guess that somewhere in Darwin RTL there's  
> included {$linklib c}.

The entire Darwin RTL is based on libc, because that is the only  
supported system interface by Apple.

As an aside: it is a bad idea to manually define sem_post and  
friends, because even if you do not get a linking error, some of  
these functions may not be implemented (e.g. in Mac OS X < 10.4,  
sem_init/sem_destroy both return ENOSYS (function not implemented),  
and you have to use sem_open/sem_unlink/sem_close instead). Better  
use TRTLEvent instead, that one masks such implementation details for  
you (and it's portable to non-*nix to boot).


Jonas