Linux library naming convention

Report any problems with CopperSpice
Post Reply
seasoned_geek
Posts: 254
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: 254
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: 447
Joined: Sat Apr 04 2015 2:32 am
Contact:

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.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Linux library naming convention

Post by seasoned_geek »

barbara wrote: Mon Sep 28 2020 11:07 pm 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?

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.

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.
Yes, a Debian package of Diamond (well my modified Diamond pending the code being included into the project). Sorry for the late response on that.

There aren't multiple ways to indicate version. There are broken half-hearted attempts and there is the one and only way the packaging system recognizes. This is why Hunspell is broken.

Code: Select all

Depends: libc6 (>= 2.27), libstdc++6 (>= 8.4), zlib1g, hunspell, libopengl0
You can't have a (>= x.N) dependency because hunspell isn't packaged properly. As a result of this many things needed different versions of Hunspell with different APIs die horribly when installed on some machines. Having completed an RPM for Diamond I can tell you the rules are basically the same even if the terminology and syntax is different.

When a developer wants a singular version because they have some reason not to upgrade they are required to do one of two things.
  • bundle the library with their application rather than use the system version (prefered)
  • Launch via a shell script which for only that process updates alternatives (frowned)
Post Reply