The mess Ubuntu 18.04 LTS has made of libreadline

June 13, 2018

I'll start with my tweet:

I see that Ubuntu still hasn't provided libreadline6 for Ubuntu 18.04 LTS, despite that being the default and best readline to compile against on both 16.04 LTS and 14.04 LTS. Binaries that work across LTS versions? Evidently we can't have that.

Even the new expanded Twitter is too little space to really explain things for people who don't already have some idea of what I'm talking about, so let's expand that out.

Let's suppose that you've built yourself a program that uses GNU Readline on an Ubuntu 14.04 or Ubuntu 16.04 machine (perhaps a custom shell). You have a mixed environment, with common binaries used across multiple hosts (for example, because you have NFS fileservers). When you try to run this program on Ubuntu 18.04, here is what will happen:

<program>: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory

What is going on here (besides there being no libreadline.so.6 on Ubuntu 18.04) is that shared libraries on Linux have a version, which is the digit you see after the .so, and programs are linked against a specific version of each shared library. This shared library version number changes if the library's ABI changes so that it wouldn't be safe for old programs to call the new version of the library (for example because a structure changed size).

The standard Ubuntu (and Debian) naming scheme for shared library packages is that 'libreadline6' is the Ubuntu package for version 6 of libreadline (ie for libreadline.so.6). So you would normally fix this problem on Ubuntu 18.04 by installing the 18.04 version of libreadline6. Unfortunately no such package exists, which is the problem.

Over the years, Ubuntu has packaged various versions of GNU Readline. Of the still supported LTS releases, 14.04 and 16.04 ship libreadline5 and libreadline6, while Ubuntu 18.04 ships libreadline5 and libreadline7 and does not have libreadline6. So, can you build a program on 14.04 or 16.04 so that it uses libreadline5, which would perhaps let you run it on 18.04? Unfortunately you can't even do this, as 14.04 and 16.04 only let you build programs that use libreadline6.

(The libreadline-dev package on 14.04 and 16.04 installs libreadline6-dev, and there is no libreadline5-dev.)

The reason Debian and Ubuntu package multiple versions of GNU Readline is for backwards compatibility, so that programs compiled on older versions of the distribution, using older versions of the shared library, will still run on the new version. That's why libreadline5 is packaged even on 18.04. But this time around, Ubuntu apparently decided to throw GNU Readline backwards compatibility to 14.04 and 16.04 under the bus for some reason, or perhaps they just didn't bother to check and notice despite the fact that this should be a routine check when putting an Ubuntu release together (especially an LTS one).

If you're in this situation, the good news is that there is a simple manual fix. Just download a suitable binary .deb of libreadline6 by hand (for example from the 16.04 package) and install it on your 18.04 system. This appears to work fine and hasn't blown up on us yet. If you have a lot of 18.04 systems to install, you probably want to add this to your install automation. Perhaps someday you'll be able to take it out in favour of installing the official Ubuntu 18.04 version of libreadline6, but based on the current state of affairs I wouldn't hold my breath about that.

(There are various standard Ubuntu programs that use GNU Readline, such as /usr/bin/ftp. However, they're all specific to the particular Ubuntu release and so they all use its GNU Readline version, whatever that is; on 18.04, they all use libreadline7. Should you copy the 16.04 ftp binary over to an 18.04 machine you'd have this problem with it too, but there's very little reason to do that; 18.04 comes with its own version of ftp, after all.)

PS: Ubuntu's Launchpad.net is such a mess that I can't even tell if this has been reported as a bug. Oh, apparently this is probably the right page, and also it looks like no such bug has been filed. It's sad that I could only find it by the 'Bug Reports' link on the packages.ubuntu.com page for it.


Comments on this page:

By Vincent Bernat at 2018-06-13 08:37:55:

Ubuntu usually tries to avoid to diverge from Debian. I think this is the case here, as the maintainer of libreadline in Debian is a Canonical employee. So, it's easier to check why libreadline6 is not in Debian anymore.

First, in the case of GNU Readline, upstream only maintains one version (currently, 7.0).

You can check here the reasons of removal of readline6: https://tracker.debian.org/pkg/readline6. Notably, it points to the following bug reports:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877240
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877197
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850287
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838234

So, basically, the transition from libreadline6 to libreadline7 is easy as the API stays the same. All packages in Debian have transitioned quickly and there is no more reverse dependencies. The package can therefore be removed safely. Moreover, a packaging bug pushed a bit the decision to remove the package.

libreadline5 is still here because there are still reverse dependencies for it (as I suppose the API is a bit different and would need source change from the reverse dependencies).

Making the packages of a distribution work together is already hard enough to not consider stuff outside the distribution. Maintaining an ever-growing number of packages with less and less volunteers is not sustainable. Old packages need to be removed.

By Opk at 2018-06-13 08:57:26:

It'd be nice if more libraries could make use of symbol versioning to avoid the need to increase the version in the SONAME. On Linux, libc, is about the only thing which does that. I've run into similar issues in the past with ncurses.

By K.C. Marshall at 2018-06-13 10:17:00:

If the API stayed the same, could you cheat and just create a symlink named "libreadline.so.6" that points to "libreadline.so.7"? Would that be better or worse than installing the 16.04 libreadline package on the 18.04 machine?

Written on 13 June 2018.
« A website's design shows its actual priorities
Link: About the memory management in the Bourne shell »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 13 00:56:39 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.