On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote:
> On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth <howa...@bromo.med.uc.edu>
> wrote:
> > Roberto,
> > I am finding the following when I build my ppl-10.1
> > packaging in fink...
> >
> > Validating .deb dir /sw/src/fink.build/root-ppl-shlibs-0.10.1-1...
> > Error: Shlibs field says compatibility version for /sw/lib/libppl.7.dylib
> > is 8.0.0, but it is actually 9.0.0.
> > Error: package contains the shared library
> > /sw/lib/ppl/libppl_java.jnilib
> > but the corresponding install_name and compatibility_version
> > %p/lib/ppl/libppl_java.jnilib 0.0.0
> > are not listed in the Shlibs field. See the packaging manual.
> > Removing runtime build-lock...
> > Removing build-lock package...
> >
> > It seems rather bad form to me that soversions are being changed in
> > minor dot releases of ppl. This has been one of my biggest fears
> > about cloog/ppl...that the so version control be randomly bumped.
>
> Looks ok for me on Linux targets. 0.10 had
>
> lrwxrwxrwx 1 root root 15 Nov 18 11:53
> /usr/lib64/libppl.so.7 -> libppl.so.7.0.0
> -rwxr-xr-x 1 root root 921473 Nov 18 11:42
> /usr/lib64/libppl.so.7.0.0
>
> and 0.10.1 now has
>
> lrwxrwxrwx 1 root root 15 Apr 14 15:28
> /usr/lib64/libppl.so.7 -> libppl.so.7.1.0
> -rwxr-xr-x 1 root root 803544 Apr 14 15:28
> /usr/lib64/libppl.so.7.1.0
>
> which is fine. Of course a more fine-grained control with
> symbol versions would be nice - but that's hard to get right with
> a C++ library.
>
> Richard.
Richard,
However if you look in ppl-0.10.1/src/Makefile.am, you will find...
# PPL release -version-info
# 0.1 -----
# 0.2 -----
# 0.3 0:0:0
# 0.4 1:0:1
# 0.5 2:0:0
# 0.6 3:0:0
# 0.7 4:0:0
# 0.8 5:0:0
# 0.9 6:0:0
# 0.10 7:0:0
# 0.10.1 8:0:1
So either Roberto meant to bump the soversion and
forgot or changed his mind and didn't revert all of the
soversion changes out before release. In any case,
it seems really weird to have soversion changes in
a 0.10.x release.
Jack
