[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Plugin API/ABI versions



Many applications allow their functionality to be extended by means of 
plugins, often in the form of libraries that the application dlopen()s. 
Usually the application provides an API, and like other APIs these APIs (and 
ABIs) can evolve, calling for versioned dependencies. But executables aren't 
shared libraries, so there are no SONAME/NEEDED tags (typically, AFAIK, the 
API headers define some version constants that the application queries the 
plugin for to detect incompatibilities) and using dpkg-shlibdeps doesn't 
work. So how should the -dev package provide correct dependency information 
in these cases?

- Should the application put necessary parts in a shared library, which 
plugins can link against, thereby making full use of symbol versions 
possible?

- Can the plugins usually simply declare the API version it's actually using 
(which it should know), overriding the version constants in the headers? More 
generally, what can cause a binary, compiled with (say) version 1.1 of 
libfoo.h instead of previously version 1.0 (i.e. it doesn't use any new parts 
of the API) to fail to work with version 1.0 of the library? Changed macros 
that cause a different symbol to be referenced comes to mind. What else, if 
symbols aren't versioned?

-- 
Magnus Holmgren        holmgren@lysator.liu.se
                       (No Cc of list mail needed, thanks)

Attachment: pgpyjuV56zYQe.pgp
Description: PGP signature


Reply to: