I'm Using Distribution $X That was shipped With Compiler $Y, but I Need Compiler Version $Z

Question

Issue

This question, and answers containing various approaches to solving it comes up many times almost daily on our exchange here. If a search result brought you here Welcome! If a comment I left in your question linked here, you can safely assume your question could be added to the list below, as it fits in the same category:

• Disagreement between glib and gcc after gcc downgrade
• How can I downgrade to a specific gcc version on Fedora 39?
• How I can install some gcc compilers in arch linux?
• Debian Bullseye: Install gcc-11.4.0 and dependencies

Those are just four of the many questions tagged under [gcc] with the search term downgrade. Those readers/users knowledgeable enough to come to the exchange first almost always ask How Can I..." Those unlucky readers that tried something that failed almost always have the phrase "It Broke", or "I think I broke something". In this question and answer, I'll attempt to explain Why mixing compilers breaks all Linux's, and in the answer I'll provide the simplest way that I know to fix the issue, that doesn't cause breakage but costs a bit of overhead in terms of time and space to setup. Since this is going to be a community contributed Question and Answer, I'm kindly going to ask you to upvote this if you like my approach.

Issue Explained

TLDR: Skip Down to Why Does Downgrading Compilers Cause Issues?

I've used the picture below two or 3 times here across various answers, and feel it provides us all with a good place to start. I realize it's big, and as such, I urge reader's to open it in a separate tab and zoom etc. if you like.

Find your distribution in that list, and then continue reading. You'll notice that your distribution has a parent distribution. OK, OK, I know the readers using the parent distributions (the ones on the far left of the timeline) are asking:

I'm using one of the ones on the far left, so where are it's parents?

And now we get to the meat of this question. For Example sake, let's fill in $X and $Y from my title (Patience Readers, $Z is coming up)

• $X = Fedora 39
• $Y = 13.2.1-6.fc39

Definitions

• Distribution (Quoting Wikipedia):

A Linux distribution (often abbreviated as distro) is an operating system made from a software collection that includes the Linux kernel and often a package management system.

• Package Management System (Quoting Again):

A package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer in a consistent manner

Knowing these two items helps us answer the Parent Distribution question, but unfortunately with another question: How Do the distribution maintainers create a distribution?

The Answer: All linux software minus the kernel is stored at and can be obtained from the GNU Software FTP Site in source code archives. All Linux Kernels are available for download in source code archives at The Linux Kernel Archives. In short, all Distributions begin from the same source code, including the parent distributions

Why Does Downgrading Compilers Cause Issues?

From the definition earlier, a distribution is a group or set of related software. This relation can be seen in your distribution's repository (or whatever else your distribution has chosen to name it).

At the time a new version (in our Example $X = Fedora 39) is made available the repository for that version is locked, specifically version locked, meaning that every package in that repository is now frozen in time. Once frozen it isn't altered. It can only live as long as the version is supported or die when the version is upgraded.

The tools required to build GCC are also in the now frozen repository. If a user attempts to upgrade or downgrade the GCC that was shipped in the frozen repository, the version locking would be broken if you were to succeed. To prevent the breakage from happening, your OS'es Package Manager prevents this.

Read my answer to find out how I overcame $Z

Answer 1

A less heavyweight solution is to use containers. Install Docker or Podman, and follow the recipe in eyoung100’s answer to identify the distribution release you’re after, or look it up on Repology.

Using the same Fedora 36 example, run a container:

podman run -it fedora:36

You can add -v options to make directories on your system available inside the container:

podman run -it -v ~/myproject:/myproject:z fedora:36

(only add :z if you‘re using SELinux).

In the container, install gcc and any other tools you need, build your project (in /myproject), and you’ll find your files in the directory you shared.

Answer 2

My Solution

First off, I guess I would be considered a purist in that if a package isn't in your repository, or can't be added from a third party repository, you shouldn't attempt to compile it from scratch or "force it to work" because doing so short-circuits your package manager. With that in mind, I present a rock-solid solution

---

Virtualization Is Our Friend

We need some tools and a bit of Hard Drive Space for this approach. I'll leave making space available to you but aside from that follow these steps:

1. Install VirtualBox with your package manager
2. Install Vagrant with your package manager

Note: Vagrant will work with Hyper-V and docker out of the box I believe (see Stephen Kitt's answer for help with docker), but I chose VirtualBox because that's what I learned first, and if needed I can install a Desktop in the VM to configure the VM further.

With our Virtualization Helpers installed we can continue. I'm continuing by:

1. Gathering Requirements - I came up as a web programmer, so let's gather requirements from our customer. For our purposes, I'm going to fill in $Z now. Using Example question 2 from the Issue heading above we have the following values:
   • $X = Fedora
   • $Y = 13.2.1-6.fc39
   • $Z = 12.x.x
2. Always use the following sentence as the Search term in your favorite engine: Which release of $X contained GCC $Z

So using our example: Which release of Fedora contained GCC 12. Now Quoting Google:

Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35. The gcc 12 is currently under development and will be included in Fedora 36 upon release. Feb 16, 2022

3. Let's check to see if the above release - 36 - is still supported. In our search engine:
   $X release history

Which would equate to Fedora release history in our example, which gives us Fedora Linux release history. Well, what do we do now? It looks like Fedora 36 is no longer supported. We added Vagrant for this very reason. If we visit The Vagrant Cloud, we can search for Fedora 36, which yields these results, and using a Vagrantfile, we can customize a full VM version and develop our application or website using the VM while saving our project files on our host system.

Reason Why I Chose This Approach

Using virtualization separates your development environment from the system you use day-to-day, and keeps you from making an irreparable mistake. I realize it will cost a bit of extra setup time, but Vagrant only needs to be installed once. A vagrantfile only needs to be created each time your project requirements change. The small learning curve for Vagrant and the Virtualization is worth the tradeoff of reinstalling an OS if a mistake is made trying to figure out how to install multiple compilers.