Ah, that's useful to know, thanks Piotr.
Ollie
From: "Piotr Stanczyk" <address@hidden>
To: address@hidden
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: address@hidden address@hidden on behalf of Peter Hillman address@hidden
Sent: 13 January 2013 22:45
To: address@hidden
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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel