Hi,
A cc is appreciated as I don't subscribe to debian-python.
On Fri, Jul 24, 2009 at 03:49:16PM +0200, Mathieu Malaterre wrote:
> On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbins<steve@sumost.ca> wrote:
> > Hi,
> >
> > Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
> > python module is wrong, with reference to an oblique comment from
> > Josselin Mouette [1].
> >
> > Is this true? ?What is the rationale for not versioning these shared
> > objects?
Chow Loong Jin responded noting that Python modules are loaded
using dlopen or similar, and not by the runtime linker. He concludes
that this implies the normal shared object versioning is not required.
I don't quite follow that logic. I guess that conventionally a module
named "fooextension.so" is loaded; i.e. without a version. However,
one could, in principle, dlopen("fooextension.so.3") if one wanted
multiple versions of fooextension to coexist. Is it simply the case
that this need has not (yet?) arisen in practice?
In any event, if convention dictates that modules are not versioned,
that's fine with me. My next question is then: does it bother people
if ITK installs versioned shared objects *in addition to* the simple
".so" link that is used by the python code? It does this currently,
just because the build process treats all shared objects (modules and
libraries) identically. Is it worth while to change this or can we
just leave it alone?
> > Is there any "more official" document that mandates this? ?For
> > example, the python policy?
>
> This issue was raised by Denis Barbier. [...]
> It would be extremely nice too if all wrap language would adopt the
> same convention.
That would be nice.
Personally, I'd settle for each language having a clear policy written
down (in a location that I can easily find) so that I don't have to
guess. ;-)
Regards,
-Steve
Attachment:
signature.asc
Description: Digital signature