Re: FFI on OS X?

[Andreas Rottmann]

address@hidden (Ludovic Courtès) writes:

> Hi Andreas,
>
> Andreas Rottmann <address@hidden> 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/>