guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FFI on OS X?


From: Ludovic Courtès
Subject: Re: FFI on OS X?
Date: Thu, 03 Mar 2011 18:50:37 +0100
User-agent: Gnus/5.110013 (No Gnus v0.13) Emacs/23.2 (gnu/linux)

Hi,

Andreas Rottmann <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:
>
>> 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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]