[Flac-dev] liboggflac1 soname
giles at xiph.org
Mon Jan 10 22:22:51 PST 2005
On Mon, Jan 10, 2005 at 09:37:18PM -0800, Josh Coalson wrote:
> as far as I can piece together, the last releases went like:
> FLAC release libOggFLAC went to
> ------------- ------------------------------------------
> 1.1.0 1:2:0 from 1:1:0 (code changes only I think)
> 1.1.1-beta1 2:0:1 from 1:2:0 (some i'faces added, some changed)
> 1.1.1 2:1:1 from 2:0:1 (code changes only, no
> interface changes)
> I think this is all according to the libtool rules in
> the 'enum renumbering' to me implied an 'interface change'
> but maybe I misinterpreted.
Yes, it's a change. The libtool manual seems a little incomplete
here. This issue is that the order of items in the enum has
changed in the header. Appending is generally safe, but because
enums are mapped to integers in the object code, an app built
against 1.1.0 would for example misinterpret what the 1.1.1
library uses for OggFLAC__STREAM_DECODER_OGG_ERROR as
As such it's an incompatible change, for which you should also
zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0,
Thanks for the changelog link. That's very clear.
> hmm... not sure what "exposed" means in the libtool numbering
> sense. the libOggFLAC++ includes do #include the libOggFLAC
> headers, but I have been (maybe erroneously) adjusting the
> libtool numbers strictly by what changed in the C++ side.
Hmm. Sounds like the same issue applies unfortunately. The real
question is whether you can upgrade them independently or not.
If not they should probably share libtool versioning numbers.
> I don't know what the custom on numbering betas is, but
> flac-1.1.1-beta1 was public and people tend to live on the edge
> linking and shipping beta stuff, so I thought it was safest to
> treat it as a real version as far as libtool numbering goes.
Yes, I agree. The numbering is all about coexisting installs of the
P.S. Hope you're feeling better!
More information about the Flac-dev