Nikolaus Rath <[email protected]> writes: > Simon McVittie <[email protected]> writes:
>> 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). That's exactly the information that the ABI is capturing. That dependency isn't artificial at all. If the ABI change involves a change to that function, then indeed the ABI restriction is achieving precisely what it is supposed to achieve. Note that, in the presence of an ABI change that affects that function, the current configuration of your application will cause it to break, whereas if the application loaded the ABI-versioned library, it would not break; it would just have a dependency on the old library, like any other program linked against the old ABI. This is what Policy is designed to support. > 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? I believe loading the versioned library is the correct solution short of reworking the application along the lines that Simon describes. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
