#26 dlvsym support in FFI


Hi All,

I have a patch for CLISP (current CVS) which adds
versioned symbol support to the dynamic FFI.

Versioned symbol support is required in order to access
versioned symbols.

Quickie background:

On a Linux system, if you view "nm /lib/libc.so.6" you find symbols with @
and @@ in their name, like "__xstat64@GLIBC_2.1". This is a versioned
symbol and can be retrieved with dlvsym("__xstat64", "GLIBC_2.1").

A dlsym("__xstat64") lookup may or may not get you that one.

C programs compiled against glibc (or other libraries) are encoded with
the version information, so they ask for the correct symbol. If
a function is superseded with a new version which is not
backward compatible at the ABI level, programs which were
compiled against the old version of the library continue to work, because
they request the old version. This is nicely transparent to the C
programmer; the linker simply pulls out the latest version of the
function that is available at the time the program is built and sticks in
the versioned reference.

CLISP programs using the FFI need also to be able to pin to a specific
version of a function, otherwise they may work with some library
installations but break with others (which are newer).


I decided that the easiest way to get this working in CLISP is to extend
the idea of what a foreign name is. Currently, it must be a string atom.
I expanded the concept so that a foreign symbol name can be either
a string, or a cons cell whose CAR and CDR are strings. This pair
of strings represents a versioned symbol.

The low-level FFI plumbing recognizes the cons, and deals with
it accordingly through dlvsym() rather than dlsym(). On platforms
where this kind of thing is not available, the lookup for a versioned
symbol simply fails.



  • Sam Steingold

    Sam Steingold - 2008-03-13

    Logged In: YES
    Originator: YES

    1. name should remain a string
    2. version should be passed on to def-call-out and dev-c-var using :version argument, similar to :library et al
    3. find-foreign-variable and find-foreign-function will need to accept an extra argument, breaking ABI (this is not a problem because ABI is already broken for 2.45 by the JITC patch)
    4. lookup_foreign_variable & lookup_foreign_function do not need to be modified to accept version because they lookup objects known at compile time
    5. foreign_library_function & foreign_library_variable do need to accept an extra version argument.
    6. a foreign variable and function objects encapsulate two facets of a foreign object: the way it looks to the C world (address, name, version) and the way it looks to the Lisp world (size, types of arguments, flags). it might make sense to abstract the foreign part (name/version/address) out of FV&FF, similar to Closure/IClosure/CClosure.

  • Sam Steingold

    Sam Steingold - 2008-03-16
    • status: open --> closed-accepted
  • Sam Steingold

    Sam Steingold - 2008-03-16

    final patch

  • Sam Steingold

    Sam Steingold - 2008-03-16

    Logged In: YES
    Originator: YES

    File Added: dlvsym.diff


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks