MacOS X dylib suppport...

[Chris Burkhardt]

Thanks, FPK! Reading that Wiki also confirmed my experiences that linking to external variables does not yet work on Mac OS X.

[savage]

FPC can link against dylibs

Yes, but why does it have to use the {$linklib} directive instead of the usual external keyword? If it cannot use the external keyword, then it seem the MacOS X version of the compiler is either buggy or incomplete.

Regarding MacOSX and SDL have a look at:

Yes I am aware of the work arounds, but I have to ask, why do we need to fake the SDL_Main when this is not required on Win32, Linux or even FreeBSD, which I thought MacOS X was based on.

Please enlighten me so I can better understand the nuances of MacOS X.

[FPK]

FPC can link against dylibs

Yes, but why does it have to use the {$linklib} directive instead of the usual external keyword? If it cannot use the external keyword, then it seem the MacOS X version of the compiler is either buggy or incomplete.

IIRC, the external 'lib' support was removed because on MacOSX the order how the libs are passed to the linker is important. So you should collect all linklib statements at one place to get them in the correct order instead of letting the compiler mess around with it.

If you don't like this behaviour, activate the code in fpc/compiler/systems/t_bsd.pas line 100

Regarding MacOSX and SDL have a look at:

Yes I am aware of the work arounds, but I have to ask, why do we need to fake the SDL_Main when this is not required on Win32, Linux or even FreeBSD, which I thought MacOS X was based on.

Please enlighten me so I can better understand the nuances of MacOS X.

From the wiki:

For Mac OS X, this is not possible because there this main function is written in Objective C.

Rewriting a C function in pascal and wrapping it is probably easy. However, to rewrite an Objective C function is hard because interfacing from Pascal to Objective C is not possible, so you can't call the Objective C functions in the converted code.

[savage]

It is in a framework called SDL.framework

Christ, does this framework then create the libSDL.dylib file or does it create a libSDL-1.2.0.dylib file, or does the {$linklib SDL} link to the frameworks and totally forget about the *.dylib file?

[Chris Burkhardt]

Chris, does this framework then create the libSDL.dylib file or does it create a libSDL-1.2.0.dylib file?

Frameworks on Mac OS X are really just directories which contain libraries, headers, and other resources. The SDL.framework contains the actual library, which is simply named SDL (not libSDL.dylib or anything).

I believe this can be ]external 'libname'[/b] style... even though the Mac version of fpc doesn't resolve libraries using the external keyword, it will still find the library and all it's symbols since it is passed to the linker using the -k option. Makes for a longer command line command, with lots of -k's, but still easy enough.

That said, I am having trouble compiling the JEDI-SDL interfaces... I think I'll start another thread about that...

Let me know if you need me to clarify. I'm somewhat a novice to all this but am happy to help if I can.

[savage]

Hi Chris,
Please start a new thread about the JEDI-SDL issues in the JEDI-SDL sub-forum. I am in the process of trying to add the definitive touches for MacOS support so any help in these stages would be most welcome.

One last question to do with the framework. In my sdl.pas, if I add the line {$linklib sdl} where the darwin declaration is, and leave everything else as is, will that be enough to link in the framework?

[Chris Burkhardt]

I'm afraid not. For two reasons:

1. /Library/Framework/SDL.framework is not in fpc's default search path, so it must be added with -Fl

Even then...

2. fpc expects libraries to be named lib*.dylib. Libraries in Frameworks have neither the "lib" prefix nor the ".dylib" suffix.

One solution is to create a symlink /usr/local/lib/libsdl.dylib pointing to /Library/Frameworks/SDL.framework/Versions/Current/SDL. (With that symbolic link then simply having {$linklib sdl} will link in the library with no additional changes or compiler flags, but otherwise not :? )

[FPK]

I recommend that you post your problems on the FPC mailing list, there are also the developers of the MacOSX port subscribed so they can help.

[Lightning]

FPK doesn't FPC support the index keyword in conjunction with external and name ?
index is the real order in the declared library and is verry useful sometimes, why use all those linklib directives when index is usable.

[Anonymous]

I can vaguely remember that you don't need to link via frameworks IF you specify the full external possibility:

All FPC unix libs are linked as follows (e.g. for gtk 1.2)

const
{$ifdef darwin}
libname = 'gtk-1.2.0';
{$linklib gtk-1.2.0}
[$endif}
{$ifdef freebsd}
libname = 'gtk12';
{$linklib gtk12}
{$endif}
{$ifdef linux}
libname = 'gtk-1.2'; // harder, multuiple distro's and convention
{$linklib gtk}
{$endif}
{$ifdef win32}
libname = 'gtk-1.2'; // harder, multuiple distro's and convention
{$linklib libgtk-0} // windows doesn't prefix lib by default, because
// it is not the default convention on windows
{$endif}

Then all functions are declared like this:

function someskeleton(a,b:integer); cdecl; external libname name 'someskeleton';

so WITH name and WITH libraryname part. FPC inserts a underscore if accessing the C namespace needs it.

I just got a laptop from work, and am creating a FreeBSD partition on it as I write , I'll try to retest Jedi-SDL header with a modern (5.3) BSD system in the coming weeks