unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Andreas Rottmann <a.rottmann@gmx.at>
Cc: Michael Ellis <michael.f.ellis@gmail.com>, guile-devel@gnu.org
Subject: Re: FFI on OS X?
Date: Thu, 03 Mar 2011 11:52:04 +0100	[thread overview]
Message-ID: <874o7kv5m3.fsf@gnu.org> (raw)
In-Reply-To: <87k4ghxgh8.fsf@gmx.at> (Andreas Rottmann's message of "Thu, 03 Mar 2011 00:14:27 +0100")

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



  parent reply	other threads:[~2011-03-03 10:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTin1oDrzx9-KxvU7DGwwLxZrRbRHs8+9ygBCwD23@mail.gmail.com>
2011-03-02 20:44 ` FFI on OS X? Ludovic Courtès
2011-03-02 21:15   ` Hans Aberg
2011-03-02 23:03     ` Ludovic Courtès
2011-03-03  9:15       ` Hans Aberg
2011-03-03 10:40         ` Ludovic Courtès
2011-03-03 11:34           ` Hans Aberg
2011-03-03 13:11             ` Ludovic Courtès
2011-03-03 14:06               ` Hans Aberg
2011-03-02 23:14     ` Andreas Rottmann
2011-03-03  9:51       ` Hans Aberg
2011-03-03 10:52       ` Ludovic Courtès [this message]
2011-03-03 13:20         ` Andreas Rottmann
2011-03-03 17:50           ` Ludovic Courtès
2011-03-09 22:04             ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874o7kv5m3.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=a.rottmann@gmx.at \
    --cc=guile-devel@gnu.org \
    --cc=michael.f.ellis@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).