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

> From: Arsen Arsenović <[email protected]>
> Cc: Eli Zaretskii <[email protected]>,  [email protected]
> Date: Mon, 10 Aug 2026 13:58:17 +0200
> 
> Richard Stallman <[email protected]> writes:
> 
> >   > 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:~$
> >
> > It looks like 28.x did work, because you report no error message from it.
> > But 27.2 failed.
> >
> > 27.2 was released in March, 2021.  That is 5 years ago.  I think we
> > shouldn't break programs that quickly!  I think our tools should
> > continue to support a program for many more years than that.
> >
> > Now that I have specific reports, I can discuss them with maintainers.
> 
> The program didn't necessarily break in this example; the admin removed
> libraries that the program was linked against.

The admin didn't remove any libraries, no.  What happened was a system
upgrade.  I don't expect a system upgrade to remove capabilities.  Am
I alone in this expectation?

> If I removed libraries that my copy of Emacs 32 was linked against, it'd
> also "break" in the same manner, even though the Emacs 32 I have
> installed was built ~18 hours ago.

Please drop the sarcasm.  This is a real problem, not a joke.

> More broadly speaking, note that, IME as a distro maintainer, programs
> quite rarely break due to issues in gcc, glibc, etc.
> 
> In the vast majority of cases, "breaks" are in things that previously
> only worked by coincidence.
> 
> For instance, the example Eli gave, of programs "breaking" because GCC
> versions up to 14 failed to properly diagnose invalid C99, the correct
> interpretation is that the programs were only "working" (in air-quotes,
> because they cannot possibly be considered working, the same way as
> someone falling off a cliff is not truly flying) because GCC in
> particular did not enforce language rules.

K&R syntax does not mean a program using it is broken, no.

> In reality, the programs have been broken for decades, often in subtle
> ways, for instance by silently being compiled into wrong code.  Indeed,
> such miscompilations were among the reasons the diagnostics were
> strengthened.
> 
> Were we to keep this broken status quo, of having a compiler that fails
> to diagnose incorrect programs, because people, 20+ years in, were not
> correcting their habits of writing incorrect code?
> 
> In my opinion, said habits are a reason to correct the status quo to
> start diagnosing incorrect code.
> 
> I don't care to relitigate that discussion further, it went on long
> enough on the GCC mailing list when it initially happen.  We've put in
> the effort of correcting existing programs, and
> https://gcc.gnu.org/gcc-14/porting_to.html was written to help everyone
> else deal with the "break".
> 
> I can't recall any actual breaks (i.e. not something like what was
> described above) in the last five years, so I'd argue we don't break
> programs that quickly.  All the breaks I can remember are simply
> instances of Hyrum's Law.

The context here is the ability (or the lack thereof) to build a
program using old enough source code.  We are proud in providing the
source code of each of our programs, indefinitely, and consider that
part of the software freedom of our users.  But in reality, try to
compile an old enough source tree, and you get gazillion warnings and
error messages, and in some cases the problem will fail to build
without a lot of non-trivial tweaking (which requires significant
expertise).  One example of this is compiling a program that used K&R
syntax.  E.g., Emacs switched to C90-style function definitions only
in version 24.1, which was released in 2012.  All the older versions
used K&R syntax; they are now "broken" by your definitions, and cannot
be easily compiled.

IOW, we cannot always keep our promise of Free Software that can
always be rebuilt and fixed using the sources we provide.  That's what
this is about.  Let's please be serious about what we promise.