Binary compatibility issues with Hugs FFI

[Antti-Juhani Kaijanaho]

Hello,

I hope I haven't missed a doc that explains all this ;-)

I've been working on packaging Green Card for Debian, and in the process
realized (with help from my fellow Debian developers) that there is
a potential problem with the Hugs FFI on Unices (and in particular
GNU/Linux systems).

Consider the following scenario:

   * Someone writes a Hugs-based application that uses the
     Hugs FFI (with the help of Green Card); the application
     causes Hugs to load a shared object.
   * A user installs the said application and compiles the shared
     object with the current GreenCard.h
   * A new Hugs is released, which changes the binary interface
     of the FFI - in the process changing GreenCard.h
   * The user installs the new Hugs.
   * The user's copy of the application breaks, as the shared object
     and Hugs are no longer compatible

How to solve this?  Clearly asking to recompile all FFI-using apps
at every change of Hugs is asking too much: the application's shared
object may be distributed in a binary-only form, or even if sources are
available, the user may lack the knowledge required in recompilation.
WRT perl modules, which have the same problem, the following has been
done:

    + Every binary module is installed into a directory which
      contains the perl version number in its name.
    + Perl only looks for modules in directories whose version match
      the perl version.
    + Thus Perl 5.005 does not load binary modules compiled for Perl
      5.004; and a site can install both versions simultaneously
      
IMHO some solution is needed, and I cannot produce one just by myself:
every other distributor of Hugs for GNU/Linux should use the same method
as I, so that people may move Hugs .so's between distributions without
recompilation.  Perhaps the Hugs authors can introduce a "foreign function
binary interface version number" that changes if and only if the binary
interface changes (like the soname of a shared library does); then we
could use this version to handle incompatible .so's in the perl manner.

Comments?

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
    (Bjarne Stroustrup, The Design and Evolution of C++, page 220)