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