similar to: liboggflac1 soname

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

On Sun, 09 Jan 2005, Ralph Giles wrote: > On Mon, Jan 10, 2005 at 12:22:18AM -0200, Henrique de Moraes Holschuh wrote: > liboggflac FROM THE 1.0.4 RELEASE has version-info 0:1:0 > liboggflac FROM THE 1.1.1 RELEASE has version-info 2:1:1 Well, the packages we are having trouble here are: flac 1.1.0 (let me check... libOggFLAC version-info 1:2:0) debian package: liboggflac1 (matches

On Sun, 09 Jan 2005, Matt Zimmerman wrote: > > Is the debian mismatch based on a release between these too? Should > > flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding > > all the packages against the 1.1.1 library should resolve the issue? Well, if something built against 1.0.4 can (even in corner cases) malfunction with 1.1.1, then yes, it must be

OK, I'm coming to this a little late (been sick) but I'll try to answer all in one mail: On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote: > > 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

On Sat, 08 Jan 2005, Ralph Giles wrote: > On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote: > > > 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

On Sun, Jan 09, 2005 at 10:56:09AM -0800, Ralph Giles wrote: > On Sun, Jan 09, 2005 at 10:44:16AM -0200, Henrique de Moraes Holschuh wrote: > > > I am holding TiMidity in the current [broken] state until we get the new > > upstream with the soname fixes. I hope it is released very soon :( > > Are we talking about the library's soname, or the debian package name?

On Mon, 10 Jan 2005, Ralph Giles wrote: > 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. [...] > Yes, I agree. The numbering is all about coexisting installs of the > various versions. Ok. I need to know what to do about this... is 1.1.2 with fixed sonames just around the

On Mon, Jan 10, 2005 at 01:36:23AM -0200, Henrique de Moraes Holschuh wrote: > Well, the packages we are having trouble here are: > flac 1.1.0 (let me check... libOggFLAC version-info 1:2:0) > debian package: liboggflac1 (matches libtool soname - ok) > > oggflac 1.1.0 not forward or backwards compatible with 1.0.4 -> ok. > oggflac 1.1.1 not forward or backwards

On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote: > > 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. Most of the changes were compatible, but it looks like

On Mon, Jan 10, 2005 at 12:22:18AM -0200, Henrique de Moraes Holschuh wrote: > Well, if something built against 1.0.4 can (even in corner cases) > malfunction with 1.1.1, then yes, it must be 2:1:0. This holds true to > the soname of the C++ libs too if changes on the underlying C libraries are > somehow exported through the C++ ones. Ok. One more time. liboggflac FROM THE 1.0.4

On Sun, Jan 09, 2005 at 10:44:16AM -0200, Henrique de Moraes Holschuh wrote: > I am holding TiMidity in the current [broken] state until we get the new > upstream with the soname fixes. I hope it is released very soon :( Are we talking about the library's soname, or the debian package name? I compared the 1.1.1 release with 1.0.4, which I think was the last stable version. The

--- Henrique de Moraes Holschuh <hmh@debian.org> wrote: > On Mon, 10 Jan 2005, Ralph Giles wrote: > > 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. > [...] > > Yes, I agree. The numbering is all about coexisting installs of the > > > various

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

/usr/bin/ld: bad -rpath option collect2: ld returned 1 exit status make[4]: *** [libFLAC.la] Error 1 --- flac-1.1.2/src/libFLAC/Makefile.in.orig 2005-02-04 21:23:37.000000000 -0500 +++ flac-1.1.2/src/libFLAC/Makefile.in 2006-04-30 20:30:00.000000000 -0400 @@ -399,7 +399,7 @@ rm -f "$${dir}/so_locations"; \ done libFLAC.la: $(libFLAC_la_OBJECTS)

On Fri, Nov 08, 2002 at 12:39:52PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > I have few notes: > > > > It seems there is changed API in CVS again. So, what about adding > > function like > > unsigned FLAC__format_frame_size(const FLAC__Frame *frame) > > which returns size of the frame in bytes. This

A follow up to the posting from January (http://lists.xiph.org/pipermail/flac/2005-January/000372.html) regarding the following error: flac: relocation error: flac: undefined symbol: OggFLAC__FileEncoderStateString: I had the same problem recently; as noted by Ralph, the problem is that when you upgrade flac, the dependent library packages are not automatically upgraded, thus you get

On 12/05/2014 15:22, Tom Stellard wrote: > On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote: >> Hello, >> >> With the release of 3.4.1, the LLVM library has been renamed from >> libLLVM-3.4.so to libLLVM-3.4.1.so. In parallel, the soname has been >> updated to >> reflect this change. >> >> AFAIK, we kept the ABI compatible from 3.4

Hello, With the release of 3.4.1, the LLVM library has been renamed from libLLVM-3.4.so to libLLVM-3.4.1.so. In parallel, the soname has been updated to reflect this change. AFAIK, we kept the ABI compatible from 3.4 to 3.4.1. So, is there any reason for doing it? This caused some breakages in Debian (basically, breaking some X because of mesa could not link against LLVM due to the new soname).

Hello, R's shared libraries are linked without setting the soname. This is causing problems for some consumers. Error: /usr/local/lib/R/library/tseries/libs/tseries.so is linked to /usr/local/lib/R/lib/libRblas.so which does not have a SONAME. math/R needs to be fixed. What's the correct way to add the necessary linker flags? I believe it should be something