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:
pgpmHnDNU_o9g.pgp
Description: PGP signature