[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] GNU Radio shared library versioning
From: |
Sylvain Munaut |
Subject: |
Re: [Discuss-gnuradio] GNU Radio shared library versioning |
Date: |
Thu, 27 Jun 2013 16:18:05 +0200 |
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
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
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