Linux library naming convention

Report any problems with CopperSpice
Post Reply
seasoned_geek
Posts: 60
Joined: Thu Jun 11 2020 12:18 pm

Linux library naming convention

Post by seasoned_geek »

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.

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)
Please note libc above

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
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.

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

Code: Select all

libCsCore1.7.so  libCsGui1.7.so  libCsNetwork1.7.so  libCsXcbSupport1.7.so
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

Code: Select all

Depends: libc6 (>= 2.27), libstdc++6 (>= 8.4), zlib1g, hunspell, libopengl0
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

Code: Select all

Version: @PACKAGE_VERSION@
in the control file placed in the DEBAIN directory of a .deb. dpkg keeps track of this information in a database.

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.
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.

seasoned_geek
Posts: 60
Joined: Thu Jun 11 2020 12:18 pm

Re: Linux library naming convention

Post by seasoned_geek »

Bye-the-bye, this is also how update-alternatives works in large part. Nice write-up on that here:

https://linuxhint.com/update_alternatives_ubuntu/

barbara
Posts: 200
Joined: Sat Apr 04 2015 2:32 am

Re: Linux library naming convention

Post by barbara »

We value your input however a few things have been lost. The naming of our libraries was not done randomly or without heavy consideration. The team does not feel bad or alone.

It is important to remember that CopperSpice is released on 16 different platforms so anything we do must be consistent across every operating system. Since we do not guarantee API at this point it would be awkward, misleading, and very confusing to say this is version "1". A developer might release an application using CS 1.7.0 and not be interested in updating to CS 1.8.0. Or a user wants to install some program that links with CS 1.7.0 and CS 1.8.0, which is fine. Our goal is to allow flexibility.

As a side issue, please know there is no such thing as a "Debian of Diamond", did you mean a Debian package for the Diamond project?

We are looking at creating packages and the naming will be set appropriately. Looking at the current Debian packages there are many which in fact do this. Just as there are multiple build systems, there are multiple ways to mark the version on a library.

Post Reply