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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
