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

Re: Rationale for Policy 8.4



Simon McVittie <smcv@debian.org> writes:
> 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.

Ah, I see. But as you already pointed out, in this case the situation is
a little bit odd:

The application only calls a single function from libpython2.6 which
takes a string as its only argument. So there really is no need to
actually compile/link against it, this would just introduce an
artificial dependency on the ABI that is not truly there (if the
parameter type changed from string to something else, the semantics
would break as well and a recompile wouldn't fix it).


I guess there is no proper way to solve this, right? Either I introduce
the artificial dependency or I need -dev to run the application?



Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


Reply to: