Re: Discussion about why GNU/Linux system upgrades cause old programs to break

> From: Richard Stallman <[email protected]>
> Cc: [email protected]
> Date: Fri, 07 Aug 2026 00:31:35 -0400
> 
> You wrote on another list,
> 
>   > My specific experience was with old versions of Emacs on a typical
>   > GNU/Linux system.  I keep past major versions on my development
>   > system, for the purposes of investigating when a particular bug or
>   > feature started happening, and it is common to have some of those old
>   > versions stop working after a system upgrade.
> 
> Can you tell us the specifics about some of those incidents?  I'd like
> us to see if by changing some practices (in Emacs or in GNU/Linux
> distros or wherever) we could improve future compatibility.

Here are some examples, from a system that identifies itself as

  $ uname -a
  Linux fencepost.gnu.org 5.4.0-208-generic #228+10.0trisquel14 SMP Tue Feb 25 00:11:13 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Trying to run old versions of Emacs I've built myself on that very
system:

  eliz@fencepost:~$ emacs-28.x/emacs-28.0.90/src/emacs -Q
  eliz@fencepost:~$ emacs-27.x/emacs-27.2/src/emacs -Q
  emacs-27.x/emacs-27.2/src/emacs: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-27.x/emacs-27.1/src/emacs -Q
  emacs-27.x/emacs-27.1/src/emacs: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-26.x/emacs-26.1/src/emacs -Q
  emacs-26.x/emacs-26.1/src/emacs: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-26.x/emacs-26.2/src/emacs -Q
  emacs-26.x/emacs-26.2/src/emacs: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-25.x/emacs-25.1/src/emacs -Q
  emacs-25.x/emacs-25.1/src/emacs: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-24.x/emacs-24.1/src/emacs -Q
  emacs-24.x/emacs-24.1/src/emacs: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-23.x/emacs-23.1/src/emacs -Q
  emacs-23.x/emacs-23.1/src/emacs: error while loading shared libraries: libgpm.so.1: cannot open shared object file: No such file or directory
  127 eliz@fencepost:~$ emacs-23.x/emacs-23.2/src/emacs -Q
  emacs-23.x/emacs-23.2/src/emacs: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

As you see, in each case some library is missing, presumably because
the OS upgrade either didn't install it or installed a newer version.
Sometimes the missing libraries are even sub-modules, like
libgtk-x11-2.0.so.0, which is probably some dependency of GTK against
which that Emacs version was linked.  Maybe these could be solved by
installing some compatibility package, but how do I find out?

Other issues are even harder to solve.  E.g., versions of Emacs that
used unexec cannot be recompiled to run on a modern GNU/Linux system
due to changes in glibc which broke assumptions made by unexec.  Such
an Emacs will crash upon startup, perhaps even when it is run as part
of the build.

> "Old versions stop working" could mean that old executables no longer
> run.  Or it could mean that old source trees do not compile.  To help
> us understand how to prevent such problems, could you please make a
> point to distinguish those two kinds of problem?

Old sources will not always easily compile on a modern system with a
new compiler.  For example, AFAIR latest versions of GCC report errors
when they see K&R style function declarations, and if it's possible to
fix that, it requires some obscure command-line option (I think GCC
folks intend to remove it in the future).

And there are other issues, too many to list all of them.  System
headers changes, for example, as well as changes in libc and other
libraries.

In sum, it is not very easy to recompile an old source tree years
after it was released.