[plt-scheme] loading libraries into memory with ffi-lib on osx

From: Jon Rafkind (workmin at ccs.neu.edu)
Date: Tue Aug 29 07:48:26 EDT 2006


Matthew Flatt wrote:
> At Tue, 29 Aug 2006 06:40:38 0800, Matthew Flatt wrote:
>   
>>> This works fine in linux and windows but on OSX it doesnt seem to work.
>>> [...]
>>>       
>> I don't think it's so different from Linux.
>>     
>
> I wasn't thinking very well. Linking in OS X is certainly different
> than in Linux.
>
> Roughly, inter-dylib references in OS X are like `(lib ...)' references
> in MzScheme modules. If your dylib links with -llibpng, then it doesn't
> matter whether some "libpng" is already loaded if that "libpng" isn't
> the one found through the lib search path. (And that's why things work
> when you put libpng in /usr/lib.)
>
> In MzScheme, when you don't want to use `lib', you can use a relative
> path. In OS X 10.4 and later, you can use a @loader_path prefix in a
> similar way. For now, I recommend against depending on 10.4 features.
>
> Another way around the problem is to add
>
>   -flat_namespace -undefined suppress
>
> to the link command, and drop the "-llibpng". The "-flat_namespace"
> part is roughly analogous to using the Scheme top-level instead of a
> module. Dropping "-llibpng" means that you don't have something like a
> top-level `(require (lib "png"))', so whatever bindings are already
> available at load time will be used. The "-undefined suppress" says
> that you intentionally didn't specify a specific source for some
> bindings. Finally, use `(ffi-lib "libpng")' before `(ffi-lib
> "liballeg")'.
>
>   
Brilliant, it works fine now. I tried using -flat_namespace before when
linking Allegro but then I got errors about Cocoa not being defined. I
guess the -undefined suppress flag helps with that.


Posted on the users mailing list.