Re: FFI on OS X?

Re: FFI on OS X?

[Ludovic Courtès]

Hi,

Michael Ellis <michael.f.ellis@gmail.com> writes:

> 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")

Thanks,
Ludo’.

Re: FFI on OS X?

[Hans Aberg]

On 2 Mar 2011, at 21:44, 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.

Re: FFI on OS X?

[Ludovic Courtès]

Hi,

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

> On 2 Mar 2011, at 21:44, 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.

May I recommend switching to GNU/Linux?  :-)

Thanks,
Ludo’.

Re: FFI on OS X?

[Hans Aberg]

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.

> May I recommend switching to GNU/Linux?  :-)

You can always try:-), but Mac OS X 10.5 Intel and later is certified UNIX, and the only parts in the UNIX standard recognizing file name extensions is 'make' and ".c" (I checked on the standardization list).

Hans

Re: FFI on OS X?

[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’.

Re: FFI on OS X?

[Hans Aberg]

On 3 Mar 2011, at 11:40, Ludovic Courtès wrote:
>>> 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.  

I recommend that too. - I brought it up a year ago, so if somebody wants to give it another take, please feel free to do it. :-)

> But keep in mind that ltdl
> should still do the right thing on those older versions of OS X
> described above.

That might be Mac OS X 10.4 or older; 10.5 and later on PPC cannot run Mac OS 9.

I have a vague memory that a year ago, some still ran Mac OS 10.4.

> 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.

Apparently not.

>> UNIX, and the only parts in the UNIX standard recognizing file name
> 
> “UNIX standard”, what a funny phrase!  :-)

Do you like "Single UNIX Specification" better?

Re: FFI on OS X?

[Ludovic Courtès]

Hi,

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

> On 3 Mar 2011, at 11:40, Ludovic Courtès wrote:
>>>> 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.
>
> I recommend that too. - I brought it up a year ago, so if somebody
> wants to give it another take, please feel free to do it. :-)

It’d boil down to summarizing the situation and proposing a way to
detect whether .dylib can be dlopen’d.  I don’t have access to OS X,
though, so I won’t look into it.

[...]

>>> UNIX, and the only parts in the UNIX standard recognizing file name
>>  “UNIX standard”, what a funny phrase!  :-)
>
> Do you like "Single UNIX Specification" better?

Sure.  :-)

Ludo’.

Re: FFI on OS X?

[Hans Aberg]

On 3 Mar 2011, at 14:11, Ludovic Courtès wrote:

>>>>> 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.
>> 
>> I recommend that too. - I brought it up a year ago, so if somebody
>> wants to give it another take, please feel free to do it. :-)
> 
> It’d boil down to summarizing the situation and proposing a way to
> detect whether .dylib can be dlopen’d.  I don’t have access to OS X,
> though, so I won’t look into it.

I think has already been done in the exchange a year ago. So it is probably coming anytime soon. :-)

Re: FFI on OS X?

[Andreas Rottmann]

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

> On 2 Mar 2011, at 21:44, 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.
>
This looks like a bug, probably in libtldl. I'd guess that on OS X, it
is *supposed to* try the .dylib extension instead of .so.  Tracing the
process to see what it actually looks for might be interesting.

Another related issue that has come up in IRC is versioning: If I
understand correctly, it is currently impossible to specify the version
of the shared object to be used (as one cannot even pass a full filename
to `dynamic-link').  This has two (IMHO) unacceptable implications:

(1) On GNU/Linux, the .so symlink has to be installed for the FFI-using
    code to work.  At least on Debian, this means that the -dev package
    (which contains that symlink) has to be installed.  In turn, any
    Guile application or library that would be packaged for Debian would
    have to depend on the -dev package.  This is Wrong(tm).  There is
    nothing inherent in a language binding for a given C library that
    would require the presence of e.g. headers and the static library
    (or library documentation, which is also often provided in the -dev
    package) *at runtime*.

(2) A language binding written using the dynamic FFI, in its simplest
    form (i.e without clever tricks such as obtaining information from
    the headers, perhaps via the C compiler), is inherently tied to a
    specific ABI of the shared library in question.  So if that language
    binding does not specify (via a version number of some sort) the ABI
    expected from the shared libary, bad things will happen.  For
    example, on an upgrade of the shared library to a new version which
    breaks the ABI, there's a good chance that the language binding will
    be broken in subtle (or not so subtle) ways.  If the expected ABI
    would be specified in the Scheme code, the binding will fail, but it
    will do so with a relatively clear error message, and not appear to
    work and then crash randomly.

Currently, guile uses lt_dlopenext(), which does not seem to provide a
way to specify ABI version information at all.  I'd propose extending
`dynamic-link' to allow for an optional second argument, similiar to
Racket's `ffi-lib'[0].  If that argument is provided, Guile would use
lt_dlopen() instead of lt_dlopenext(), passing it a shared library name
containing the specified ABI information.  Of course the mangling of the
library name and ABI version would depend on the platform, but on
GNU/Linux, it would work something like this:

(dynamic-link "libSDL-1.2" '("0")) ;; calls: lt_dlopen("libSDL-1.2.so.0")

[0] http://docs.racket-lang.org/foreign/Loading_Foreign_Libraries.html?q=ffi-lib#(def._((lib._ffi/unsafe..rkt)._ffi-lib))

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: FFI on OS X?

[Hans Aberg]

On 3 Mar 2011, at 00:14, Andreas Rottmann 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.
>> 
> This looks like a bug, probably in libtldl. I'd guess that on OS X, it
> is *supposed to* try the .dylib extension instead of .so.  

Yes, and try without adding a file name extension.

> Tracing the
> process to see what it actually looks for might be interesting.

I made a softlink ending in .so, and then it worked.

> Another related issue that has come up in IRC is versioning: If I
> understand correctly, it is currently impossible to specify the version
> of the shared object to be used (as one cannot even pass a full filename
> to `dynamic-link').

The full path works, as long as the name of library actually opened ends in .so.

Re: FFI on OS X?

[Ludovic Courtès]

Hi Andreas,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Another related issue that has come up in IRC is versioning: If I
> understand correctly, it is currently impossible to specify the version
> of the shared object to be used (as one cannot even pass a full filename
> to `dynamic-link').  This has two (IMHO) unacceptable implications:
>
> (1) On GNU/Linux, the .so symlink has to be installed for the FFI-using
>     code to work.  At least on Debian, this means that the -dev package
>     (which contains that symlink) has to be installed.  In turn, any
>     Guile application or library that would be packaged for Debian would
>     have to depend on the -dev package.  This is Wrong(tm).  There is
>     nothing inherent in a language binding for a given C library that
>     would require the presence of e.g. headers and the static library
>     (or library documentation, which is also often provided in the -dev
>     package) *at runtime*.

I understand and I agree that this is a real problem, but this looks to
me like a Debian-centric discussion.  I think ltdl’s file lookup rules
should not be changed just to abide by the packaging rules of a distro.

> (2) A language binding written using the dynamic FFI, in its simplest
>     form (i.e without clever tricks such as obtaining information from
>     the headers, perhaps via the C compiler), is inherently tied to a
>     specific ABI of the shared library in question.  So if that language
>     binding does not specify (via a version number of some sort) the ABI
>     expected from the shared libary, bad things will happen.

This is not news.  :-)

> Currently, guile uses lt_dlopenext(), which does not seem to provide a
> way to specify ABI version information at all.  I'd propose extending
> `dynamic-link' to allow for an optional second argument, similiar to
> Racket's `ffi-lib'[0].  If that argument is provided, Guile would use
> lt_dlopen() instead of lt_dlopenext(), passing it a shared library name
> containing the specified ABI information.  Of course the mangling of the
> library name and ABI version would depend on the platform, but on
> GNU/Linux, it would work something like this:
>
> (dynamic-link "libSDL-1.2" '("0")) ;; calls: lt_dlopen("libSDL-1.2.so.0")
>
> [0] http://docs.racket-lang.org/foreign/Loading_Foreign_Libraries.html?q=ffi-lib#(def._((lib._ffi/unsafe..rkt)._ffi-lib))

Can you show actual uses of this of the VERSION argument?

As I mentioned in another message, the SONAME and file name is a
system-dependent thing.  So my impression is that it would be impossible
to use it portably.

IMO the Right Thing to do on GNU systems (and Solaris, at least) would
be to allow ‘dynamic-func’ to use symbol versioning [0].  That would be
finer-grain and would not rely on SONAME magic numbers.

Thanks,
Ludo’.

[0] http://thread.gmane.org/gmane.lisp.guile.devel/9933

Re: FFI on OS X?

[Andreas Rottmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Andreas,
>
> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Another related issue that has come up in IRC is versioning: If I
>> understand correctly, it is currently impossible to specify the version
>> of the shared object to be used (as one cannot even pass a full filename
>> to `dynamic-link').  This has two (IMHO) unacceptable implications:
>>
>> (1) On GNU/Linux, the .so symlink has to be installed for the FFI-using
>>     code to work.  At least on Debian, this means that the -dev package
>>     (which contains that symlink) has to be installed.  In turn, any
>>     Guile application or library that would be packaged for Debian would
>>     have to depend on the -dev package.  This is Wrong(tm).  There is
>>     nothing inherent in a language binding for a given C library that
>>     would require the presence of e.g. headers and the static library
>>     (or library documentation, which is also often provided in the -dev
>>     package) *at runtime*.
>
> I understand and I agree that this is a real problem, but this looks to
> me like a Debian-centric discussion.  I think ltdl’s file lookup rules
> should not be changed just to abide by the packaging rules of a distro.
>
This is not just Debian (and derivatives), I just used Debian as an
example sice it is what I know best.  Splitting out files needed only
for development is a common practice on at least Fedora[0], and
OpenSuSE[1], and I suspect most distributions that ship binary packages.

[0] http://fedoraproject.org/wiki/PackagingGuidelines#Devel_Packages
[1] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Examples

>> Currently, guile uses lt_dlopenext(), which does not seem to provide a
>> way to specify ABI version information at all.  I'd propose extending
>> `dynamic-link' to allow for an optional second argument, similiar to
>> Racket's `ffi-lib'[0].  If that argument is provided, Guile would use
>> lt_dlopen() instead of lt_dlopenext(), passing it a shared library name
>> containing the specified ABI information.  Of course the mangling of the
>> library name and ABI version would depend on the platform, but on
>> GNU/Linux, it would work something like this:
>>
>> (dynamic-link "libSDL-1.2" '("0")) ;; calls: lt_dlopen("libSDL-1.2.so.0")
>>
>> [0]
>> http://docs.racket-lang.org/foreign/Loading_Foreign_Libraries.html?q=ffi-lib#(def._((lib._ffi/unsafe..rkt)._ffi-lib))
>
> Can you show actual uses of this of the VERSION argument?
>
> As I mentioned in another message, the SONAME and file name is a
> system-dependent thing.  So my impression is that it would be impossible
> to use it portably.
>
Yep, you are right (unfortunatly ;-)).  However, I think most
"interesting" libraries today use libtool, which uses a portable,
common-denominator mechanism to supply version information (see "7.2
Libtool's versioning system" in the libtool manual), centered around the
concept of an interface number represented as an integer.  So I guess it
might be possible to specify this libtool interface number and extend
libltdl to map this to the right system-specific magic number/name.

> IMO the Right Thing to do on GNU systems (and Solaris, at least) would
> be to allow ‘dynamic-func’ to use symbol versioning [0].  That would be
> finer-grain and would not rely on SONAME magic numbers.
>
Having symbol versioning support is certainly a good thing to have, but
it requires upstream supporting it -- not all libraries provide
versioned symbols.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: FFI on OS X?

[Ludovic Courtès]

Hi,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andreas Rottmann <a.rottmann@gmx.at> writes:
>>
>>> Another related issue that has come up in IRC is versioning: If I
>>> understand correctly, it is currently impossible to specify the version
>>> of the shared object to be used (as one cannot even pass a full filename
>>> to `dynamic-link').  This has two (IMHO) unacceptable implications:
>>>
>>> (1) On GNU/Linux, the .so symlink has to be installed for the FFI-using
>>>     code to work.  At least on Debian, this means that the -dev package
>>>     (which contains that symlink) has to be installed.  In turn, any
>>>     Guile application or library that would be packaged for Debian would
>>>     have to depend on the -dev package.  This is Wrong(tm).  There is
>>>     nothing inherent in a language binding for a given C library that
>>>     would require the presence of e.g. headers and the static library
>>>     (or library documentation, which is also often provided in the -dev
>>>     package) *at runtime*.
>>
>> I understand and I agree that this is a real problem, but this looks to
>> me like a Debian-centric discussion.  I think ltdl’s file lookup rules
>> should not be changed just to abide by the packaging rules of a distro.
>>
> This is not just Debian (and derivatives), I just used Debian as an
> example sice it is what I know best.  Splitting out files needed only
> for development is a common practice

We were talking about splitting out ‘.so’ files specifically, not
headers, etc.  Do Fedora & co. move ‘.so’ to dev packages too?

>>> Currently, guile uses lt_dlopenext(), which does not seem to provide a
>>> way to specify ABI version information at all.  I'd propose extending
>>> `dynamic-link' to allow for an optional second argument, similiar to
>>> Racket's `ffi-lib'[0].  If that argument is provided, Guile would use
>>> lt_dlopen() instead of lt_dlopenext(), passing it a shared library name
>>> containing the specified ABI information.  Of course the mangling of the
>>> library name and ABI version would depend on the platform, but on
>>> GNU/Linux, it would work something like this:
>>>
>>> (dynamic-link "libSDL-1.2" '("0")) ;; calls: lt_dlopen("libSDL-1.2.so.0")
>>>
>>> [0]
>>> http://docs.racket-lang.org/foreign/Loading_Foreign_Libraries.html?q=ffi-lib#(def._((lib._ffi/unsafe..rkt)._ffi-lib))
>>
>> Can you show actual uses of this of the VERSION argument?
>>
>> As I mentioned in another message, the SONAME and file name is a
>> system-dependent thing.  So my impression is that it would be impossible
>> to use it portably.
>>
> Yep, you are right (unfortunatly ;-)).  However, I think most
> "interesting" libraries today use libtool, which uses a portable,
> common-denominator mechanism to supply version information (see "7.2
> Libtool's versioning system" in the libtool manual),

Yes, but the mapping of this to the SONAME and file name is
system-dependent.  See ‘version_type’ in libtool (info "(libtool)libtool
script contents"), and see how version variables are computed:

  http://git.sv.gnu.org/cgit/libtool.git/tree/libltdl/config/ltmain.m4sh#n6598

> centered around the concept of an interface number represented as an
> integer.  So I guess it might be possible to specify this libtool
> interface number and extend libltdl to map this to the right
> system-specific magic number/name.

Ltdl could do the conversion above like libtool does, but transferring
that knowledge from ltmain.sh to ltdl may not be trivial.

Anyway, it can’t hurt to propose it to the Libtool gurus.

>> IMO the Right Thing to do on GNU systems (and Solaris, at least) would
>> be to allow ‘dynamic-func’ to use symbol versioning [0].  That would be
>> finer-grain and would not rely on SONAME magic numbers.
>>
> Having symbol versioning support is certainly a good thing to have, but
> it requires upstream supporting it -- not all libraries provide
> versioned symbols.

Yes.

Thanks,
Ludo’.

Re: FFI on OS X?

[Andy Wingo]

On Thu 03 Mar 2011 18:50, ludo@gnu.org (Ludovic Courtès) writes:

> Do Fedora & co. move ‘.so’ to dev packages too?

Yep.

Andy
-- 
http://wingolog.org/