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 11:52:04 +0100
User-agent: Gnus/5.110013 (No Gnus v0.13) Emacs/23.2 (gnu/linux)

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.

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



reply via email to

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