Re: Having trouble creating a shared library package
On Sat, Dec 08, 2018 at 01:09:48PM -0800, John Horigan wrote: > You are right, the soname should not change. If I change the ABI version > to 2:6:0 then the BSD soname will still be libagg2. Then if I have a patch > that changes it to 3:0:1 in the debian package, the soname will still be > libagg2; because Linux subtracts the age from current to get the soname > number. TBH I don't see any reason to do that in the package, if the soname stays the same. The soname is all that matters. -- WBR, wRAR signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
On Sat, Dec 8, 2018 at 11:00 AM Andrey Rahmatullin wrote: > On Sat, Dec 08, 2018 at 09:38:17AM -0800, John Horigan wrote: > > This is what I found in the configure.ac file: > > > > dnl Setting up library version > > AGG_LIB_VERSION="2:4:0" > > dnl current-´ / / > > dnlrevision--´ / > > dnl age---´ > > dnl Update the version information only immediately before a public > release > > of antigrain > > dnl If the library source code has changed, increment revision (c:r:a > > becomes c:r+1:a). > > dnl If any interfaces have been added, removed, or changed since the last > > update, > > dnl increment current, and set revision to 0. > > dnl If any interfaces have been added since the last public release, then > > increment age. > > dnl If any interfaces have been removed since the last public release, > then > > set age to 0. > > > > > > These instructions match what I found on the web for Linux library ABI > > versions. Since I am changing the library source, adding an interface, > but > > not removing any interfaces I should increment the current to 3, reset > the > > revision to 0 and increment the age to 1 --> 3:0:1 (not 2:0:1 as I said > > before). So the soname will be libagg3. > Making debian soname incompatible with upstream is a serious thing with > long consequences, are you sure you want to do that? And are you sure that > you want to use a soname that will be used by the upstream in the future, > for a different ABI? > > You are right, the soname should not change. If I change the ABI version to 2:6:0 then the BSD soname will still be libagg2. Then if I have a patch that changes it to 3:0:1 in the debian package, the soname will still be libagg2; because Linux subtracts the age from current to get the soname number. > -- > WBR, wRAR >
Re: Having trouble creating a shared library package
On Sat, Dec 08, 2018 at 09:38:17AM -0800, John Horigan wrote: > This is what I found in the configure.ac file: > > dnl Setting up library version > AGG_LIB_VERSION="2:4:0" > dnl current-´ / / > dnlrevision--´ / > dnl age---´ > dnl Update the version information only immediately before a public release > of antigrain > dnl If the library source code has changed, increment revision (c:r:a > becomes c:r+1:a). > dnl If any interfaces have been added, removed, or changed since the last > update, > dnl increment current, and set revision to 0. > dnl If any interfaces have been added since the last public release, then > increment age. > dnl If any interfaces have been removed since the last public release, then > set age to 0. > > > These instructions match what I found on the web for Linux library ABI > versions. Since I am changing the library source, adding an interface, but > not removing any interfaces I should increment the current to 3, reset the > revision to 0 and increment the age to 1 --> 3:0:1 (not 2:0:1 as I said > before). So the soname will be libagg3. Making debian soname incompatible with upstream is a serious thing with long consequences, are you sure you want to do that? And are you sure that you want to use a soname that will be used by the upstream in the future, for a different ABI? -- WBR, wRAR signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
This is what I found in the configure.ac file: dnl Setting up library version AGG_LIB_VERSION="2:4:0" dnl current-´ / / dnlrevision--´ / dnl age---´ dnl Update the version information only immediately before a public release of antigrain dnl If the library source code has changed, increment revision (c:r:a becomes c:r+1:a). dnl If any interfaces have been added, removed, or changed since the last update, dnl increment current, and set revision to 0. dnl If any interfaces have been added since the last public release, then increment age. dnl If any interfaces have been removed since the last public release, then set age to 0. These instructions match what I found on the web for Linux library ABI versions. Since I am changing the library source, adding an interface, but not removing any interfaces I should increment the current to 3, reset the revision to 0 and increment the age to 1 --> 3:0:1 (not 2:0:1 as I said before). So the soname will be libagg3. -- john On Sat, Dec 8, 2018 at 5:11 AM Andrey Rahmatullin wrote: > On Fri, Dec 07, 2018 at 05:31:10PM -0800, John Horigan wrote: > > Upstream is going to bump the version to 2.6 (skipping 2.5 because of an > > abandoned agg2.5 fork). I plan to change the ABI version to 2:0:1. > I'm not familiar with the libtool version crap^Wscheme, does this mean you > are going to change the soname as compared to the upstream? > > -- > WBR, wRAR >
Re: Having trouble creating a shared library package
On Fri, Dec 07, 2018 at 05:31:10PM -0800, John Horigan wrote: > Upstream is going to bump the version to 2.6 (skipping 2.5 because of an > abandoned agg2.5 fork). I plan to change the ABI version to 2:0:1. I'm not familiar with the libtool version crap^Wscheme, does this mean you are going to change the soname as compared to the upstream? -- WBR, wRAR signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
On 2018-12-07 17:06 -0800, John Horigan wrote: > On Fri, Dec 7, 2018 at 8:36 AM Wookey wrote: > On 2018-12-07 08:27 -0800, John Horigan wrote: > Normally the library package > libfoo is shared, and the libfoo-dev package contains the static > version. You already have the static version in libagg-dev, so why not > just add libagg as the shared version, and be like any other library > in debian? > > That makes much more sense. I tried it, and the packages all build with no > lintian errors or warnings. I was able to remove all my lintian overrides too. Good. > > Can you explain why you think there should be two -dev packages? > > If I create a new version of libagg-dev package and add shared libraries then > dependent packages that use the new version will link against the shared > library instead of the static library. Well, it's up to the depending package whether it builds against the shared or the static library. > The resulting binaries will then depend > on the shared libraries being installed. Wouldn't this break things? Why should it? This is the normal state of afairs for the vast majority of libraries in Debian. Any depending package building against the shared version needs to declare that dependency. But if it continues to build aginst the static version then it can continue to not mention such a dependency. > I created > libagg2-dev so that libagg-dev users would not get shared libraries that they > don't expect. How are the depending packages configuring this library? Are they using pkg-config, or do they just have fixed makefile configs? Or some other kind of config-script ? If that config is coming from the libagg-dev package then you can (probably) control which is the default. If it's coming from the depending package then the behaviour should continue as before (unless it was only falling-back to the static lib after failing to find the shared lib?) So I still don't think you need more than the standard: libaggN (shared library) libagg-dev (static library, headers, maybe pkgconfig file) Then check if any depending packages builds break. We don't normally control dynamic/static linking in debian by having two alternative libfoo-dev packages. We always provide both and let packages choose which they want to use. It is probably _possible_ to do what you suggest, but I don't see any reason to try and do so yet. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
On Fri, Dec 7, 2018 at 8:50 AM Andrey Rahmatullin wrote: > On Fri, Dec 07, 2018 at 08:27:24AM -0800, John Horigan wrote: > > I maintain a static library package, libagg-dev. There is an outstanding > > request for a shared library of libagg. > Is building the shared lib supported by the upstream? > Yes, but the the package maintainer before me made it a static-only package. libagg 2.4 is API incompatible with libagg 2.3 and the upstream developers did not follow semantic versioning by setting the version to 3.0. The package maintainer did not understand that ABI versions (current:revision:age) do not need to match the upstream version scheme. The library version for libagg2.4 is 2:4:0 for no good reason at all. Upstream is going to bump the version to 2.6 (skipping 2.5 because of an abandoned agg2.5 fork). I plan to change the ABI version to 2:0:1. Technically the ABI version should be 3:x:y because of the agg2.3 to agg2.4 API changes. But that happened 9 years ago, so I don't see the point. > > > libagg2-dev has the .so file with the name libagg.so and libagg2 has the > > .so file with the name libagg.so.2.0.4 and the symlink libagg.so.2. > You shouldn't put the soname version into the -dev package name. > And libagg.so is a symlink to libagg.so.2, not its copy. > > > I also put in lintian overrides because libagg2-dev installs a .so file > > with the SONAME libagg2 but the package is called libagg2-dev: > You should not override this, of course. > With your input and help from Wookey I have removed all of my lintian overrides. I'm still trying to resolve whether I need two -dev packages or one. > > -- > WBR, wRAR >
Re: Having trouble creating a shared library package
On Fri, Dec 7, 2018 at 8:36 AM Wookey wrote: > On 2018-12-07 08:27 -0800, John Horigan wrote: > > I maintain a static library package, libagg-dev. There is an outstanding > > request for a shared library of libagg. I'm leaving the original > libagg-dev > > binary package as it is, with just the static libraries. I'm adding > binary > > packages libagg2-dev and libagg2. libagg2-dev has everything that > libagg-dev > > has, plus the shared library. libagg2 has just the shared library. > > This is atypical for debian packages. Normally the library package > libfoo is shared, and the libfoo-dev package contains the static > version. You already have the static version in libagg-dev, so why not > just add libagg as the shared version, and be like any other library > in debian? > > That makes much more sense. I tried it, and the packages all build with no lintian errors or warnings. I was able to remove all my lintian overrides too. > Can you explain why you think there should be two -dev packages? > > If I create a new version of libagg-dev package and add shared libraries then dependent packages that use the new version will link against the shared library instead of the static library. The resulting binaries will then depend on the shared libraries being installed. Wouldn't this break things? I created libagg2-dev so that libagg-dev users would not get shared libraries that they don't expect. > > I can't find any definitive information about what should be in a shared > > library SONAME-dev package and SONAME (runtime) package in the /usr/lib/ > > directory. But I looked at the installed files in many > libfoo-dev/ > > libfoo package pairs and it seems like I should have this: > > > > ~john$ ls -l libagg2-dev/usr/lib/x86_64-linux-gnu/ > > total 1584 > > -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so > > ~john$ ls -l libagg2/usr/lib/x86_64-linux-gnu/ > > total 216 > > lrwxrwxrwx 1 root root 15 Dec 6 23:14 libagg.so.2 -> libagg.so.2.0.4 > > -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so.2.0.4 > > > > libagg2-dev has the .so file with the name libagg.so and libagg2 has the > .so > > file with the name libagg.so.2.0.4 and the symlink libagg.so.2. > > > > But I get a lintian error: > > > > E: libagg2-dev: ldconfig-symlink-missing-for-shlib > usr/lib/x86_64-linux-gnu/ > > libagg.so.2 usr/lib/x86_64-linux-gnu/libagg.so libagg.so.2 > > > > I also put in lintian overrides because libagg2-dev installs a .so file > with > > the SONAME libagg2 but the package is called libagg2-dev: > > > > libagg2-dev binary: package-name-doesnt-match-sonames * > > libagg2-dev binary: non-dev-pkg-with-shlib-symlink * > > > > So what is the deal with -DEV packages and shared libraries? What am I > supposed > > to do? > > I can help explain this in more detail (as I've been doing a lot of > this recently, and I agree it's confusing), but lets sort out whether > you really need libagg-dev _and_ libagg2-dev first. I think you don't, > and that's just complicating matters. > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ >
Re: Having trouble creating a shared library package
On Fri, Dec 07, 2018 at 08:27:24AM -0800, John Horigan wrote: > I maintain a static library package, libagg-dev. There is an outstanding > request for a shared library of libagg. Is building the shared lib supported by the upstream? > libagg2-dev has the .so file with the name libagg.so and libagg2 has the > .so file with the name libagg.so.2.0.4 and the symlink libagg.so.2. You shouldn't put the soname version into the -dev package name. And libagg.so is a symlink to libagg.so.2, not its copy. > I also put in lintian overrides because libagg2-dev installs a .so file > with the SONAME libagg2 but the package is called libagg2-dev: You should not override this, of course. -- WBR, wRAR signature.asc Description: PGP signature
Re: Having trouble creating a shared library package
On 2018-12-07 08:27 -0800, John Horigan wrote: > I maintain a static library package, libagg-dev. There is an outstanding > request for a shared library of libagg. I'm leaving the original libagg-dev > binary package as it is, with just the static libraries. I'm adding binary > packages libagg2-dev and libagg2. libagg2-dev has everything that libagg-dev > has, plus the shared library. libagg2 has just the shared library. This is atypical for debian packages. Normally the library package libfoo is shared, and the libfoo-dev package contains the static version. You already have the static version in libagg-dev, so why not just add libagg as the shared version, and be like any other library in debian? Can you explain why you think there should be two -dev packages? > I can't find any definitive information about what should be in a shared > library SONAME-dev package and SONAME (runtime) package in the /usr/lib/ > directory. But I looked at the installed files in many libfoo-dev/ > libfoo package pairs and it seems like I should have this: > > ~john$ ls -l libagg2-dev/usr/lib/x86_64-linux-gnu/ > total 1584 > -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so > ~john$ ls -l libagg2/usr/lib/x86_64-linux-gnu/ > total 216 > lrwxrwxrwx 1 root root 15 Dec 6 23:14 libagg.so.2 -> libagg.so.2.0.4 > -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so.2.0.4 > > libagg2-dev has the .so file with the name libagg.so and libagg2 has the .so > file with the name libagg.so.2.0.4 and the symlink libagg.so.2. > > But I get a lintian error: > > E: libagg2-dev: ldconfig-symlink-missing-for-shlib usr/lib/x86_64-linux-gnu/ > libagg.so.2 usr/lib/x86_64-linux-gnu/libagg.so libagg.so.2 > > I also put in lintian overrides because libagg2-dev installs a .so file with > the SONAME libagg2 but the package is called libagg2-dev: > > libagg2-dev binary: package-name-doesnt-match-sonames * > libagg2-dev binary: non-dev-pkg-with-shlib-symlink * > > So what is the deal with -DEV packages and shared libraries? What am I > supposed > to do? I can help explain this in more detail (as I've been doing a lot of this recently, and I agree it's confusing), but lets sort out whether you really need libagg-dev _and_ libagg2-dev first. I think you don't, and that's just complicating matters. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Having trouble creating a shared library package
I maintain a static library package, libagg-dev. There is an outstanding request for a shared library of libagg. I'm leaving the original libagg-dev binary package as it is, with just the static libraries. I'm adding binary packages libagg2-dev and libagg2. libagg2-dev has everything that libagg-dev has, plus the shared library. libagg2 has just the shared library. I can't find any definitive information about what should be in a shared library SONAME-dev package and SONAME (runtime) package in the /usr/lib/ directory. But I looked at the installed files in many libfoo-dev/libfoo package pairs and it seems like I should have this: ~john$ ls -l libagg2-dev/usr/lib/x86_64-linux-gnu/ total 1584 -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so ~john$ ls -l libagg2/usr/lib/x86_64-linux-gnu/ total 216 lrwxrwxrwx 1 root root 15 Dec 6 23:14 libagg.so.2 -> libagg.so.2.0.4 -rw-r--r-- 1 root root 219072 Dec 6 23:14 libagg.so.2.0.4 libagg2-dev has the .so file with the name libagg.so and libagg2 has the .so file with the name libagg.so.2.0.4 and the symlink libagg.so.2. But I get a lintian error: E: libagg2-dev: ldconfig-symlink-missing-for-shlib usr/lib/x86_64-linux-gnu/libagg.so.2 usr/lib/x86_64-linux-gnu/libagg.so libagg.so.2 I also put in lintian overrides because libagg2-dev installs a .so file with the SONAME libagg2 but the package is called libagg2-dev: libagg2-dev binary: package-name-doesnt-match-sonames * libagg2-dev binary: non-dev-pkg-with-shlib-symlink * So what is the deal with -DEV packages and shared libraries? What am I supposed to do? -- john
