Linux library naming convention
Posted: Sun Sep 27 2020 4:16 pm
I stumbled onto this creating the Diamond Debian and wanted to bring it up for consideration. Hunspell has the exact same problem so CopperSpice shouldn't feel alone.
Please note libc above
Only the base ABI number is in the name and that only changes when there are massive ABI changes/breakage. If you lived through the migration from libc5 to libc6 you know the pain. A convention rose of linking only to an ABI base symbolic link so things wouldn't break that were linked against version 1.7 when 1.8 replaced it on a running system.
Libraries that aren't unique in functionality tend to have a steep uphill climb when trying to get included in Debian based distros or Debian itself. (Hunspell mostly got in because of LibreOffice and the mad dash away from OpenOffice when Oracle bought SUN.)
I humbly suggest CopperSpice adopt the mainstream convention of creating a base ABI symbolic link instead of creating the following:
Ultimately someone will create a Debian and probably an RPM packaging script for CopperSpice if it is going to be included with a distro. The libraries will then be in a standard system directory like /usr/lib or /usr/local/lib or some such thing. If they are named the way they are now, when version 1.8 comes out and gets lain down on top of 1.7 (removing 1.7) everything linked against 1.7 will break. (That's the part I stumbled into when trying to install a Debian of Diamond built on Ubuntu 18.04 LTS on Ubuntu 20.04 LTS.)
The control file placed in the DEBIAN directory of a .deb file typically has a line like this
The (>= something.other) after a package means you need a version greater than or equal to that version. Ultimately the "version" as far as packaging is concerned is controlled by a line like this
in the control file placed in the DEBAIN directory of a .deb. dpkg keeps track of this information in a database.
The "install" portion of the build needs to create symlinks wherever the libraries are installed too.
libCsCore.so.1
libCsGui.so.1
libCsNetwork.so.1
libCsXcbSupport.so.1
When you have a huge ABI/API breakage you can change them to 2 or whatever.
Been a long time since I looked at RPM creation or internals, but I seem to remember functional (not syntactical) similarity when it came to versioning.
Code: Select all
roland@roland-U18CS-VirtualBox:~/Projects/diamond_debian_release$ ldd diamond
linux-vdso.so.1 (0x00007fffb3329000)
libCsGui1.7.so => /home/roland/Projects/diamond_debian_release/./libCsGui1.7.so (0x00007fc1401c0000)
libCsCore1.7.so => /home/roland/Projects/diamond_debian_release/./libCsCore1.7.so (0x00007fc13f5a2000)
libhunspell-1.6.so.0 => /usr/lib/x86_64-linux-gnu/libhunspell-1.6.so.0 (0x00007fc13f333000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc13efaa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc13ed92000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc13e9a1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc13e782000)
libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007fc13e554000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc13e337000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc13df99000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc143ab7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc13dd95000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007fc13dadf000)
Code: Select all
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
Code: Select all
roland@roland-U18CS-VirtualBox:~/Projects$ ls -al /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Jun 4 12:25 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.27.so
Code: Select all
roland@roland-U18CS-VirtualBox:~/Projects$ ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1.2) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
roland@roland-U18CS-VirtualBox:~/Projects$
I humbly suggest CopperSpice adopt the mainstream convention of creating a base ABI symbolic link instead of creating the following:
Code: Select all
libCsCore1.7.so libCsGui1.7.so libCsNetwork1.7.so libCsXcbSupport1.7.so
The control file placed in the DEBIAN directory of a .deb file typically has a line like this
Code: Select all
Depends: libc6 (>= 2.27), libstdc++6 (>= 8.4), zlib1g, hunspell, libopengl0
Code: Select all
Version: @PACKAGE_VERSION@
Code: Select all
roland@roland-HP-Compaq-Elite-8300-SFF:~$ dpkg -l diamond
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii diamond 2.0.0 amd64 This is the Diamond text editor.
libCsCore.so.1
libCsGui.so.1
libCsNetwork.so.1
libCsXcbSupport.so.1
When you have a huge ABI/API breakage you can change them to 2 or whatever.
Been a long time since I looked at RPM creation or internals, but I seem to remember functional (not syntactical) similarity when it came to versioning.