On Mon, 05 Apr 2010 at 11:39:49 -0400, Nikolaus Rath wrote:
> Can someone explain to me the reason behind this policy? What's wrong
> with shipping libpython2.6 so in python2.6 / why should an application
> dlopen() libpython2.6.so.1 rather than libpython2.6.so?
The rationale probably doesn't apply very much to Python, but here it is:
the bit after .so is the ABI version. If you compiled against ABI version 1,
but your dlopen() picks up libpython2.6.so.2 (via the .so symlink), then that's
not the library you wanted, but instead an incompatible later version; if you
use the incompatible part, you'll probably crash, and could even have security
vulnerabilities as a result of the ABI mismatch.
For instance, if you call a function foo(int, int) in the dlopened library,
but ABI version 2 changed it to foo(long long, double), you'll have problems
(but the incompatibility would be fixed by a simple recompile!).
The thing to do would be to pick up the SONAME at compile time, and use that
as the thing you dlopen(). Alternatively, assuming the Python-related code
is an optional part, you could split out the Python-related code
into a plugin, link that plugin against libpython2.6 in the normal
shared-library way, and dlopen the plugin (which is what I'd personally do);
if libpython2.6 is missing, the dlopen will fail and your application will
carry on without its optional Python support.
Simon
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive:
http://lists.debian.org/[email protected]
