Jan Engelhardt on Sun, 16 Dec 2012 09:30:56 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Strange mix of SO version for libpari.so


On Friday 2012-11-30 11:55, Bill Allombert wrote:
>On Fri, Nov 30, 2012 at 03:27:04AM +0100, Jan Engelhardt wrote:
>> 
>> Compiling pari-2.5.3 (the problem goes back to at least 2.5.0) produces 
>> a libpari.so.2.5.3, but uses -Wl,-soname,libpari.so.3. What is the 
>> reason that this obvious mismatch has been put into the Makefile?
>
>There is no mismatch: libpari.so.2.5.3 is the filename, and
>libpari.so.3 is the SONAME. They do not have to be identical.
>[...]
>See this FAQ entry <http://pari.math.u-bordeaux.fr/faq.html#versionnum>
>and especially the link
><http://pari.math.u-bordeaux.fr/archives/pari-dev-0206/msg00092.html>

Indeed they need not be; packaging pari for openSUSE merely raised
eyebrows because the filename is non-standard.
An overview:

(1.)
The overwhelming majority of all distro-provided libraries one usually
has installed in /usr/lib follows libfoo.so.x -> libfoo.so.x.y, not
libfoo.so.x -> libfoo.so.2.(x/2+1).z.

So if pari followed common practice, it would just use
 pari 2.5.0: libpari.so.3 -> libpari.so.3.0.0
 pari 2.5.1: libpari.so.3 -> libpari.so.3.0.1
 etc.

(2.)
Recognizing that there may exist some people who find using
libpari.so.3.0.x for 2.5.x odd, unfitting or simply undesired,
there is another way exercised:

09:17 nakamura:/usr/lib64 > ls -log libasm* libdw* libelf*
-rwxr-xr-x 1  31408 Jul 16 05:57 libasm-0.153.so
lrwxrwxrwx 1     15 Sep 21 13:17 libasm.so.1 -> libasm-0.153.so
-rwxr-xr-x 1 224576 Jul 16 05:57 libdw-0.153.so
lrwxrwxrwx 1     14 Sep 21 13:18 libdw.so.1 -> libdw-0.153.so
-rwxr-xr-x 1  84536 Jul 16 05:57 libelf-0.153.so
lrwxrwxrwx 1     15 Sep 21 09:25 libelf.so.1 -> libelf-0.153.so

so the filename would be "libpari-2.5.3.so". (Using this name has
a side-effect: using -lpari-2.5.3 becomes available. Whether that
actually is useful, I don't know.)


As for development branches, your filename/SONAME choices [msg000092.html]
are conclusive and follow established practices, no
objections there :)