Displaying 3 results from an estimated 3 matches for "flac_1_1_1".
Did you mean:
flac_1_1_3
2005 Jan 08
4
liboggflac1 soname
On Sun, Jan 09, 2005 at 02:03:28AM -0200, Henrique de Moraes Holschuh wrote:
> *AND* there is a major problem with liboggflac1.
>
> liboggflac1 did not change the soname (better check this, it might require a
> soname change, check the seekable ogg-flac support stuff).
CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac?
If so, it needs a soname change.
>
2005 Jan 10
3
liboggflac1 soname
...e 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.
> 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 wha...
2005 Jan 10
0
liboggflac1 soname
...nu.org/software/libtool/manual.html#SEC35
the 'enum renumbering' to me implied an 'interface change'
but maybe I misinterpreted.
a more detailed list of what changed between 1.1.0 and 1.1.1
is here (scroll down to the libraries section):
http://flac.sourceforge.net/changelog.html#flac_1_1_1
unfortunately I don't have anything that concise for earlier
versions but I can dig it out of CVS if needed.
--- Ralph Giles <giles@xiph.org> wrote:
> If, in fact, the underlying C library is somehow exposed in
> liboggflac++ then, as you suggest, we do have a problem there.
>...