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 :)