GNU Radio shared library versioning

GNU Radio
1

I’ve been looking at splitting up the library packages in OE for
embedded GNU Radio and have run across this issue in master.

[libgnuradio-filter-3.7git.so.0.0.0]
[libgnuradio-core-3.7git.so.0.0.0]
[libboost_date_time-mt.so.1.48.0]

Comparing the strings extracted from the .so with readelf, we can see
the gnuradio libraries are not properly versioned (I show the boost one
for comparison).

I expect to see:

libgnuradio-filter.so.3.7.0

Not having a sane version number creates headaches for me when trying to
package the libraries cleanly and without a lot of hacking around.
Fixing the root problem would be a good thing, and make GNU Radio look
more like a professional system and not a prototyping one.

Does anyone have any inight into why this is like this before I start
looking at the problem?

Philip

2

Hi,

[libboost_date_time-mt.so.1.48.0]

Not necessarely so, see on my system :

lrwxrwxrwx 1 root root 36 Dec 16 2012
/usr/lib/libboost_date_time-mt-1_49.so →
libboost_date_time-mt-1_49.so.1.49.0
-rwxr-xr-x 1 root root 72168 Dec 16 2012
/usr/lib/libboost_date_time-mt-1_49.so.1.49.0
lrwxrwxrwx 1 root root 29 Dec 16 2012
/usr/lib/libboost_date_time-mt.so → libboost_date_time-mt-1_49.so

Comparing the strings extracted from the .so with readelf, we can see
the gnuradio libraries are not properly versioned (I show the boost one
for comparison).

I expect to see:

libgnuradio-filter.so.3.7.0

You should read

The 3 numbers there are the 3 numbers after the .so.xxx

Imagine you have libXXX.so.1.2.3 and the libXXX.so & libXXX.so.1
symbolic link which is the common style.

In general the libXXX.so should point to whatever you want to link to
when compiling a new software and using -lXXX
The binary will then contain the info that it will try to load
libXXX.so.1 and that implies that all libXX.so.1.N.N have the same
ABI.
The .2.3 part should only be used for internal revisions that don’t
change any thing externally so that a software compiled against an
older lib will be able to load the new one without any issue.

This would clearly not be the case for libgnuradio.3 …

Cheers,

Sylvain
3

On 06/27/2013 10:18 AM, Sylvain M. wrote:

/usr/lib/libboost_date_time-mt-1_49.so.1.49.0

The binary will then contain the info that it will try to load
libXXX.so.1 and that implies that all libXX.so.1.N.N have the same
ABI.
The .2.3 part should only be used for internal revisions that don’t
change any thing externally so that a software compiled against an
older lib will be able to load the new one without any issue.

This would clearly not be the case for libgnuradio.3 …

So you are suggesting 3.7 should really be 4.0.0 for shared lib
versioning sanity?

Philip

4

So you are suggesting 3.7 should really be 4.0.0 for shared lib
versioning sanity?

If you wanted to remove the version number from the lib name itself,
yes, there would be no real relation between the official “version”
3.7.x and the actual .so name.

Including the official name in the library itself seems common
(looking at my /usr/lib) when you have so drastic changes between
versions that you might as well consider them separate libs with no
change of operating anyway.

So I guess the current choice is probably not an accident and most
likely a good one.

Cheers,

Sylvain