[Flac-dev] liboggflac1 soname

[Josh Coalson]

--- Ralph Giles <giles at xiph.org> wrote:
> 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
> > http://www.gnu.org/software/libtool/manual.html#SEC35
> > 
> > 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 
> OggFLAC__STREAM_DECODER_END_OF_STREAM.
> 
> 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,
> not 2:0:1.

I still don't see why it should have been 2:0:0... some interfaces
were added, and some were changed, and none removed, so according
to those doc's steps:

3. code changed => 1:2:0->1:3:0
4. i'faces added&changed => 1:3:0->2:0:0
5. i'faces added => 2:0:0->2:0:1
6. no i'faces removed

so I still don't see how the numbering could have broken something
or how I would fix it in the next release. unless:

> > http://flac.sourceforge.net/changelog.html#flac_1_1_1
> 
> 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.

...maybe this is what caused the problem?  i.e. some underlying
change in libFLAC.

also, just read Henrique's later email... this is probably
what happened.  for the next release I will make sure that
the numbers are bumped up enough to be right again.  but I
don't have a timeline for the next release... it is mostly
ready but I'm still trying to get time to integrate a bunch
of PPC optimizations.

I'm OK with Matt doing a 1.1.1a just to fix the sonames
though.

Josh


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com