-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I'm having this problem with the latest code from git:
root@boxie:~/gsm# git clone git://git.osmocom.org/libosmocore.git Cloning into 'libosmocore'... remote: Counting objects: 8770, done. remote: Compressing objects: 100% (4055/4055), done. remote: Total 8770 (delta 5642), reused 6765 (delta 4265) Receiving objects: 100% (8770/8770), 1.62 MiB | 142 KiB/s, done. Resolving deltas: 100% (5642/5642), done. root@boxie:~/gsm# cd libosmocore root@boxie:~/gsm/libosmocore# autoreconf -fi libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./config.guess' libtoolize: copying file `./config.sub' libtoolize: copying file `./install-sh' libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:5: installing `./missing' src/Makefile.am: installing `./depcomp' root@boxie:~/gsm/libosmocore# dpkg-buildpackage dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): -D_FORTIFY_SOURCE=2 dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): -Wl,-Bsymbolic-functions -Wl,-z,relro dpkg-buildpackage: source package libosmocore dpkg-buildpackage: source version 0.7.0 dpkg-buildpackage: source changed by Harald Welte laforge@gnumonks.org dpkg-buildpackage: host architecture amd64 dpkg-source --before-build libosmocore
[...]
make[1]: Entering directory `/home/rhizomatica/gsm/libosmocore' sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'` dh_install dh_install: usr/lib/libosmogsm.so.5.1.0 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/libosmogsm.so.5 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/libosmoctrl.so.0.0.0 exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/libosmoctrl.so.0 exists in debian/tmp but is not installed to anywhere dh_install: missing files, aborting make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory `/home/rhizomatica/gsm/libosmocore' make: *** [binary] Error 2 dpkg-buildpackage: error: debian/rules binary gave error exit status 2
So, it looks like it's trying to build a libosmogsm6 package, but only libosmogsm5.1.0 gets built. I looked around, and the only reference I found is in src/gsm/Makefile.am, and it's correct (6:0:1). What am I doing wrong? :) Cheers
Ciaby
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 08/31/2014 03:07 PM, Ciaby wrote:
I'm having this problem with the latest code from git:
[...]
So, it looks like it's trying to build a libosmogsm6 package, but only libosmogsm5.1.0 gets built. I looked around, and the only reference I found is in src/gsm/Makefile.am, and it's correct (6:0:1). What am I doing wrong? :)
This is a tentative patch to fix the issue. It works for me, libosmogsm6 and libosmoctrl0 are built successfully, however I'm not sure if that's the right thing to do. Cheers
Ciaby
On Sun, Aug 31, 2014 at 04:02:17PM -0500, Ciaby wrote:
Hi!
So, it looks like it's trying to build a libosmogsm6 package, but only libosmogsm5.1.0 gets built. I looked around, and the only reference I found is in src/gsm/Makefile.am, and it's correct (6:0:1). What am I doing wrong? :)
This is a tentative patch to fix the issue. It works for me, libosmogsm6 and libosmoctrl0 are built successfully, however I'm not sure if that's the right thing to do.
can you try to use the -M option? It will show plain renames.
--- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -1,6 +1,6 @@ # This is _NOT_ the library release version, it's an API version. # Please read Chapter 6 "Library interface versions" of the libtool documentation before making any modification -LIBVERSION=6:0:1 +LIBVERSION=6:0:0
that is odd. What build issue do you get without the versioning?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/01/2014 01:43 PM, Holger Hans Peter Freyther wrote:
On Sun, Aug 31, 2014 at 04:02:17PM -0500, Ciaby wrote:
Hi!
So, it looks like it's trying to build a libosmogsm6 package, but only libosmogsm5.1.0 gets built. I looked around, and the only reference I found is in src/gsm/Makefile.am, and it's correct (6:0:1). What am I doing wrong? :)
This is a tentative patch to fix the issue. It works for me, libosmogsm6 and libosmoctrl0 are built successfully, however I'm not sure if that's the right thing to do.
can you try to use the -M option? It will show plain renames.
Ok, will do.
--- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -1,6 +1,6 @@ # This is _NOT_ the library release version, it's an API version. # Please read Chapter 6 "Library interface versions" of the libtool documentation before making any modification -LIBVERSION=6:0:1 +LIBVERSION=6:0:0
that is odd. What build issue do you get without the versioning?
libosmogsm gets built as libosmogsm.so.5.1.0, which of course doesn't work if you try to package libosmogsm6. Also, libosmoctrl is missing libosmoctrl0.install in debian/ and the package declaration in debian/rules. My build box is Ubuntu 12.04, 64-bit, all packages updated. This is the updated patch. Cheers
Ciaby
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/02/2014 12:46 PM, Ciaby wrote: [...]
This is the updated patch.
Ops, wrong patch :) Cheers
Ciaby
On Tue, Sep 02, 2014 at 12:46:14PM -0500, Ciaby wrote:
-LIBVERSION=6:0:1 +LIBVERSION=6:0:0
that is odd. What build issue do you get without the versioning?
libosmogsm gets built as libosmogsm.so.5.1.0, which of course doesn't work if you try to package libosmogsm6. Also, libosmoctrl is missing libosmoctrl0.install in debian/ and the package declaration in debian/rules.
5 vs. 6 and missing libosmoctrl is obvious. But why doesn't 6.0.1 as version work? I would be a bit surprised if that doesn't work.
$ dpkg -S /usr/lib/liblwres.so.90.0.7 liblwres90: /usr/lib/liblwres.so.90.0.7
I will probably just build the package and then drop that hunk.
holger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/03/2014 01:13 AM, Holger Hans Peter Freyther wrote: [...]
5 vs. 6 and missing libosmoctrl is obvious. But why doesn't 6.0.1 as version work? I would be a bit surprised if that doesn't work.
$ dpkg -S /usr/lib/liblwres.so.90.0.7 liblwres90: /usr/lib/liblwres.so.90.0.7
I will probably just build the package and then drop that hunk.
I know, it doesn't make sense... but that's what I got out of building it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it? Cheers
Ciaby
On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote:
I will probably just build the package and then drop that hunk.
I know, it doesn't make sense... but that's what I got out of building it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it?
yes, it is odd. 6:0:1 gives me a so where the major version is 5 something :)
There seems to be a similar issue with the libosmocore library as well. Did you see the warning generated by lintian?
Hi Holger, Ciaby,
On 3.09.2014 16:25, Holger Hans Peter Freyther wrote:
On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote:
I know, it doesn't make sense... but that's what I got out of building it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it?
yes, it is odd. 6:0:1 gives me a so where the major version is 5 something :)
There seems to be a similar issue with the libosmocore library as well. Did you see the warning generated by lintian?
It is normal that 6:0:1 gives a so with major version 5, because 6:0:1 means that the library supports interfaces 5 and 6
See http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
So, libtool library versions are described by three integers: current The most recent interface number that this library implements. revision The implementation number of the current interface. age The difference between the newest and oldest interfaces that this library implements. In other words, the library implements all the interface numbers in the range from number current - age to current.
Vasil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 09/03/2014 10:57 AM, Vasil Velichkov wrote:
Hi Holger, Ciaby,
On 3.09.2014 16:25, Holger Hans Peter Freyther wrote:
On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote:
I know, it doesn't make sense... but that's what I got out of building it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it?
yes, it is odd. 6:0:1 gives me a so where the major version is 5 something :)
There seems to be a similar issue with the libosmocore library as well. Did you see the warning generated by lintian?
It is normal that 6:0:1 gives a so with major version 5, because 6:0:1 means that the library supports interfaces 5 and 6
Ok, that's what I found as well. So, what's the solution here? Keep packaging it as 5, or move to 6-only? Cheers
Ciaby
On Wed, Sep 03, 2014 at 06:01:31PM -0500, Ciaby wrote:
Ok, that's what I found as well. So, what's the solution here? Keep packaging it as 5, or move to 6-only?
-#define OSMO_NUM_DLIB 7 +#define DLCTRL -8 +#define OSMO_NUM_DLIB 8
might break ABI, so let's stick with 6:0:0. Could you updated your patch to address the libosmocore4 warning as well?
thanks holger
On Wed, Sep 03, 2014 at 06:57:50PM +0300, Vasil Velichkov wrote:
Hi Holger, Ciaby,
On 3.09.2014 16:25, Holger Hans Peter Freyther wrote:
On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote:
I know, it doesn't make sense... but that's what I got out of building it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it?
yes, it is odd. 6:0:1 gives me a so where the major version is 5 something :)
There seems to be a similar issue with the libosmocore library as well. Did you see the warning generated by lintian?
It is normal that 6:0:1 gives a so with major version 5, because 6:0:1 means that the library supports interfaces 5 and 6
See http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
So, libtool library versions are described by three integers: current The most recent interface number that this library implements. revision The implementation number of the current interface. age The difference between the newest and oldest interfaces thatthis library implements. In other words, the library implements all the interface numbers in the range from number current - age to current.
Right.
A new library version that still supports the previous interfaces needs to bump current and age, if the base is 6:0:0, then the update needs to be 7:0:1.
If you remove interfaces you don't want anymore, ie. you break backward compatibility, you have to reset age and bump current, ie. 7:0:0