Ah, that's useful to know, thanks Piotr. Ollie
----- Original Message ----- > From: "Piotr Stanczyk" <pstanc...@ilm.com> > To: openexr-devel@nongnu.org > Sent: Monday, 14 January, 2013 6:30:42 PM > Subject: Re: [Openexr-devel] Patch-compatibilty with versioned > namespaces > Hi, > +1 on what Peter mentioned. > You can do one more thing with the --enable-namespaceversioning flag, > it can take an optional value. > For example, you may want to pass --enable-namespaceversioning=DNeg, > in which case the DNeg suffix will be used for the internal > namespaces. (That should be reflected in the status output of the > configure script) > The build process will then generate sonames of the type: > libIlmThread-DNeg.so.10 > with the corresponding library names: > libIlmThread-DNeg.so.10.0.0 > It seems that the choice of this configure option on my part was less > than obvious - I'll update the documentation accordingly. > Piotr > ________________________________________ > From: openexr-devel-bounces+pstanczyk=ilm....@nongnu.org > [openexr-devel-bounces+pstanczyk=ilm....@nongnu.org] on behalf of > Peter Hillman [pet...@wetafx.co.nz] > Sent: 13 January 2013 22:45 > To: openexr-devel@nongnu.org > Subject: Re: [Openexr-devel] Patch-compatibilty with versioned > namespaces > Hi Ollie! > > Am I right in saying that, without versioned namespaces, patches > > are always binary compatible and minor versions always > > incompatible? > Yes, this should be the case > > Is there a patch-compatible namespacing method already provided > > (and if so, what is it)? > The existing method is patch-compatible: patches will still be > released > with the _2_0_0 namespace. We will only move from on from _2_0_0 and > .so.20 if binary compatibility has to be broken. > So, v2.0.X releases would all use the _2_0_0 namespace for all > classes. > If binary compatibility needs to be broken, we will most likely > update > the effected libraries to namespace _2_1_0, at which time the .so > version number will be bumped up to .so.21. This way, a large > application can safely load both old and new libraries. Indeed, this > ability is one of the reasons for switching to this versioned > namespace > scheme. > > What's the soname version number based on? > The soname version number (probably) tracks the first two digits of > the > namespace version number. > (the last digit in the namespace version is somewhat misleading, as > it > doesn't imply patch level: it's there only for an edge case of > providing > multiple versions of an object within the same .so but in different > namespaces, which we're really hoping we don't need to do in official > releases, but for internal builds might be the easiest way out of a > hole) > At least, that's my understanding of the plan! > Peter > On 09/01/13 03:10, Ollie Harding wrote: > > Hi, > > > > I wonder if somebody could clarify some versioning info for me, or > > point me at the bits of the docs which I've skimmed over too > > quickly? > > > > I'm building v2.0.0 using the --enable-namespaceversioning flag for > > ./configure, which gives me e.g. > > > > Imath_2_0_0::SingMatrixExc::~SingMatrixExc() > > > > This will of course mean that I cannot drop in a future v2.0.1 > > library since the Imath_2_0_0 symbols will no longer exist, > > although the library will presumably still share the .so.20 > > soname. I suspect I'm using the wrong method of making a unique > > namespace, as I in fact want a namespace which retains patch > > compatibility, e.g. maybe Imath_2_0. > > > > So my questions are: > > > > * Am I right in saying that, without versioned namespaces, patches > > are always binary compatible and minor versions always > > incompatible? > > * Is there a patch-compatible namespacing method already provided > > (and if so, what is it)? > > * What's the soname version number based on? > > > > Many thanks, > > > > Ollie > > > > _______________________________________________ > > Openexr-devel mailing list > > Openexr-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/openexr-devel > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
