Re: FFI on OS X?

[ludo@gnu.org (Ludovic Courtès)]

Hi Hans,

Hans Aberg <haberg-1@telia.com> writes:

> On 3 Mar 2011, at 00:03, Ludovic Courtès wrote:
>
>>>>> scheme@(guile-user)> (define libm (dynamic-link
>>>>> "/usr/lib/libm.dylib")) ERROR: In procedure dynamic-link: file:
>>>>> "/usr/lib/libm.dylib", message: "file not found"
>>>>  You should omit the extension, which will be automatically
>>>> inferred by Guile (actually ltdl) depending on the system:
>>>> 
>>>> (dynamic-link "/usr/lib/libm")
>>>> 
>>>> or:
>>>> 
>>>> (dynamic-link "libm")
>>>  None of those work - I checked and rechecked that. Making a soft
>>> link ending on ".so", and it works fine. I have seen this before in
>>> the Bessel function example.
>>  Right.  There’s this insightful test started by you last year:
>> 
>>  http://lists.gnu.org/archive/html/bug-libtool/2010-02/msg00000.html
>> 
>> The crux is that on older MacOS X versions ‘.dylib’ are shared
>> libraries (not dlopenable), whereas ‘.so’ are “bundles”
>> (dlopenable).  That’s why lt_dlopenext (which is what ‘dynamic-link’
>> uses) doesn’t try to open ‘.dylib’ files.
>
> The shared libraries (not dynamically loadable, except as when
> starting up the program like some web browser plugins) were on the PPC
> platform (XCOFF and PEF I think it was).
>
> Now (Mac OS 10.5 and later), all is loadable. Haven't seen any .so
> files, except as coming from GNU/Linux.

I would recommend discussing this with the Libtool folks, to see how
ltdl could adapt to the new situation.  But keep in mind that ltdl
should still do the right thing on those older versions of OS X
described above.

Perhaps lt_dlopenext could look for .dylib files if and only if it’s on
one of these newer OS X versions.  If you can tell Libtool people how
exactly ltdl can determine whether .dylib can be dlopened or not, then
you’re all set.

> UNIX, and the only parts in the UNIX standard recognizing file name

“UNIX standard”, what a funny phrase!  :-)

Thanks,
Ludo’.