My thoughts on Slackware, life and everything

Tag: abi

Fun and games in -current when ABIs break

Oh my.
It was not an April Fools joke when the ChangeLog.txt of slackware-current mentioned the following (I left out the non-relevant package updates):


Sun Apr 1 02:53:26 UTC 2018
l/icu4c-61.1-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.
l/poppler-0.63.0-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.

All of us  who follow Slackware’s development know that “shared library version bump” means ABI breakage. I.e. a lot of 3rd-party binaries will suddenly not find required library versions anymore. In particular icu4c and poppler are nasty beasts. Slackware’s own packages had been carefully updated and recompiled where needed of course, so there was no breakage in the distro itself. But many people do not run a bare Slackware installation… a lot of software is usually installed on top. And that is the software which will be affected by an incompatible change like this one on April 1st.

What’s this  version bump all about? How is it possible that it affects your computer so deeply?

Most programs depend on other programs. Software developers hate to re-invent the wheel if they can avoid it. Lots of lower-level or widely used functionality has been put into software libraries. Think of network access functionality, text rendering, encryption etc – smart people have created useful, efficient and robust software and stuffed that code into libraries. Your own program can link against these libraries at run-time and access the functionality they have to offer and your program needs.
If many programs link to the same libraries, that reduces the memory footprint because a library has to be loaded into memory only once even if many programs are using it. These libraries are therefore called ‘shared libraries‘ or ‘shared objects‘ (hence the extension ‘.so‘) or also dynamic libraries. For this dynamic linking to work, programs use binary interfaces at runtime that were established when the program was compiled and linked.
A shared library version only needs to change if the Application Binary Interface (ABI) changes. When that happens, all binaries that depend on the library need to be recompiled to adjust to the new ABI.
Among others, an ABI depends on the machine architecture, and on the toolchain (compiler, linker) used to generate the binary code from its sources. An ABI guarantees binary compatibility: the program will work on every machine with the same ABI, without a need for recompilation.

When will an ABI usually change?

One case is when the library’s API (Application Programming Interface, i.e. the way in which access to the library routines is defined in its source code) changes. This mostly occurs in software that is not yet stable and where its programmers add new functionality or revise the methods of calling the library’s functionality. Mature software on the other hand has a well-defined API which is rarely subject to change.

Another case is when the toolchain is updated. Slackware’s toolchain has been very stable and ABI changes have seldomly been introduced. As an example, Patrick talks about the a.out to ELF migration and the libc5 to glibc migration in a 2012 interview.

So why does well-established software like icu4c and poppler change their ABI almost on every minor release, thereby pissing off a really large crowd? You tell me. Arrogance or sloppiness, but let’s attribute it to bad project management. Because it probably could have been avoided in many if not all cases.

Anyway, some of you upgraded first to this new batch of updates in -current, then found out that some 3rd party packages stopped working, and then started looking for a cause.
Folks: if you are running slackware-current, you always check the ChangeLog.txt first. And if you spot a “shared library version bump” you stop right there and assess the situation. Some friends on LinuxQuestions were a bit more vocal about the way they had found themselves at a dead Plasma5 screen… others understood the situation better and and realized they had to wait for 3rd party packagers to update their repositories instead of assuming ill will.
If you are unable to cope with this kind of occasional breakage, use a stable Slackware release. That’s what all of us have been telling you all along.

My packages have been affected as well:

  • Plasma 5 stopped working,
    The fix is to recompile several packages among which a number of big ones: qt5, qt5-webkit and calligra. That means, you will have to have patience. The 64bit repository has been updated in the meantime. After upgrading from my ‘ktown’ repository your Plasma5 will again be fully functional. The 32bit repository updates will hopefully follow tomorrow have been uploaded now. I had to restart the 32bit qt5 compilation because of an internal compiler error halfway.
    The updated Plasma5 will even have some new functionality – since i slipped in the KMymoney program which otherwise would have been introduced at the April update of ‘ktown‘.
  • LibreOffice stopped working.
    The 64bit packages have been recompiled. They have been updated actually since there was a micro source version bump from to yesterday – my luck! The 32bit packages have to wait until after ‘ktown‘ updates have been completed and then I will upload them. New libreoffice packages for -current are now available.
  • Pale Moon stopped working.
    I was able to recompile the packages inbetween the Plasma5 compilation because it only takes little time. The updated palemoon packages are already in my repository.
  • Calibre stopped working.
    This will have to wait until after all the other updates New calibre packages for -current are now available..

And probably other stuff is broken too but I have not yet spotted that. If you find breakage, please report it so that I can recompile the package.

Rebuilt packages for Plasma5 (ktown)

The updates in Slackware-current this week (icu4c, poppler, libical) broke many programs in my Plasma5 ‘ktown’ repository, to the extent that the complete Plasma 5 desktop would no longer start.

That is the fun of using the bleeding edge – if something disruptive happens in slackware-current you’ll have to wait for the 3rd party repositories to catch up. And I am one of those 3rd party packagers.

I have researched the list of packages that needed a recompilation, and in some cases I performed an upgrade at the same time (qt5 went up to 5.9.3, poppler synced to the 0.62.0 in Slackware-current, qtav went up to 1.12.0). The 64bit packages have already been uploaded but if you are running 32bit Slackware-current (why are you doing that?) you’ll have to wait another day because I just started the compilation there.

What has been updated in the ‘ktown’ repository? Here is a list, mostly in order of compilation:


Every package in kdepim? Well yeah, there were many broken packages and it was simply faster to recompile all of kdepim and be done with it.

Users of slackpkg+ will be up & running fast with these updates; the others probably just need to download the individual packages I listed above from a mirror like

When the 32bit package set has been finished The 32bit packages have now been recompiled and uploaded to the repository.

I will also recompile whatever is needed in the ‘testing’ repository (that’s where the Wayland related packages are stored).

Other – not related to Plasma5 – updates/rebuilds are coming soon have finally been uploaded too. Those are LibreOffice, Pale Moon, Calibre; these programs are also affected by the updates in slackware-current but the urgency was lower than with the Plasma5 desktop.

Cleanups from the -current update fallout

blueSW-64pxI think I have managed to fix most of the important breakage in my packages, after Slackware-current updated its icu4c package a couple of days ago.

Recompiled packages are now available for -current:

  • Regular packages: LibreOffice 5.0.3
  • KDE 5_15.11 packages: qt5 (which was bumped to 5.5.1 at the same time), step, akonadi4, akonadi, akonadi-search, akonadi-calendar and kdepimlibs. Here at home, Plasma 5 works again on latest slackware-current.
  • Multilib: fixed convertpkg-compat32 script so that it will properly handle the new eudev; and also updated the “compat32” package directory with a new eudev-compat32 package.

If there are other packages in my -current repository that require recompilation, please let me know!


© 2024 Alien Pastures

Theme by Anders NorenUp ↑