Where can I obtain this specific gcc version

In order to build the driver under kernel 6.0.8-1.fc32, I need to obtain and install additional gcc version, specifically

10.3.1 20210422 (Red Hat 10.3.1-1)

Why? Because when I try to build the driver with dkms, it fails with notorious message:

  The kernel was built by: gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)
  You are using:          gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)

Any pointer would be appreciated.

Could I skip gcc version check somehow and force make, and when so, should I?



Not so hard to find …

Thank you. To many it is known that I don’t use Google, which obviously was the reason I couldn’t find it. Although it wasn’t exactly what I was looking for, I will accept it as a solution because it gave me a definitive lead to the right package at:


I will try to compile it and install it now and will be back with the outcome.

To many it is known that I don’t use Google, which obviously was the reason I couldn’t find it.


Wizardry …

1 Like

Well, no link from ddg lead to 10.3.1.-20210422, as I already said.

Well, no link from ddg lead to 10.3.1.-20210422, as I already said.

Are you sure about that? Or, can you just not help yourself from posting misinformation?

Since, I’m feeling festive & feel sorry for your affliction of being unable to read or think and, solely depending upon blindly following others …

I’ve amended the link in an effort to spoon feed you just a bit more.

Please don’t give up helping. I have a few bumps more. thank you in advance.

I have a few bumps more. thank you in advance.


1 Like

Unfortunately, following your Google search link and being able to find only package from the link above, all I got after compiling gcc and trying to install the driver via dkms was

 The kernel was built by: gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)
  You are using:           gcc (GCC) 10.3.1 20210422

So, is there any direct pointer how to get gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)?

Just guessing but, looks as though what you’ve requested and thus built is vanilla version of the gcc source available from Red Hat sans any Qubes specific patching.

Here is a reference point to help you better understand the purpose of the - separator:


Maybe find the current gcc source used by Qubes?

A search of the official repo

1 Like

I’m reluctant to step in to what seems to be a private conversation.

To see what versions of packages are available:
dnf list --showduplicate PACKAGE

To install a specific version:

In this specific case:
dnf install gcc-10.3.1-1.fc32
That will give you the specific version that you want as you can confirm
by gcc --version


Thanks anyway, appreciated indeed.
Unfortunately, nowhere such a package, either in Qubes or Fedora repo. Nothing even below v.12.
The only thing I found was installed package in dom0

libgcc.x86_64 10.3.1-1.fc32

I never thought this could be so hard to find…

This is basic use of dnf, and covered in numerous guides online.

You can use the --releasever= option to test packages from different releases.
Enable the updates repository.


dnf list --showduplicates --releasever=35 gcc
Available Packages
gcc.x86_64        11.2.1-1.fc35     fedora
gcc.x86_64        11.3.1-1.fc35     updates

Try another:

dnf list --showduplicates --releasever=33 gcc
Available Packages
gcc.x86_64        10.2.1-3.fc33     fedora
gcc.x86_64        10.3.1-1.fc33     updates


dnf list --showduplicates --releasever=32 gcc
Available Packages
gcc.x86_64        10.0.1-r0.11.fc32     fedora
gcc.x86_64        10.3.1-1.fc32         updates


1 Like

Indeed. Unless…

**Ignoring repositories: updates, updates-testing**
Installed Packages
gcc.x86_64                       12.2.1-4.fc37                          @updates
Available Packages
gcc.x86_64                       10.0.1-0.11.fc32                       fedora

Sometimes I mean very often, basic knowledge is far from enough.
As you already know, this doesn’t work for us using cacher because older releases are moved to archive, whose URL differs from baseURL manually set in repo.

So, it has to be somehow occurred this could be found in fc32 updates repository when automatic checking is not possible, hence the subject of this topic.
But that’s not all. Even when I set specific archive repo for the baseURL, this is what is gotten

Installed Packages
gcc.x86_64                       12.2.1-4.fc37                          @updates
Available Packages
gcc.x86_64                       10.0.1-0.11.fc32                       fedora  
gcc.x86_64                       10.0.1-0.11.fc32                           updates 

Which means, there is no way to get info that this package exists when using cacher even if it occurred to me it could be there.

At the end I had the choice to manually browse it, find and download it there, or to set http metalink, and change dom0 RPC policy for this specific template to update out of cacher.

But even that is not all. What if updates repo is disabled?

There’s more…

Now when I know where the package is, it was actually needed to get its source at

because neither automatically or when downloading it manually it is likely that it will agree to install it with dnf or rpm, due to version conflicts. It’s possible that someone will suggest using --force to force-install an incompatible version of gcc. Such advice is fairly likely to result in an unbootable brick.

So the only practical answer is to download and build gcc yourself with a custom configuration that installs gcc into a non-default location, in order to avoid issues with libstdc++ and libsanitizer. Not a trivial task, which at the end makes the basic knowledge so non-basic.

I am compiling at the moment and it will last, so let’s see if this is the right version.

Thank you for the hint @unman, although I just realized you don’t use cacher for Fedora, hahah.

No luck…

  The kernel was built by: gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)
  You are using:           gcc (GCC) 10.3.1 20210422

To be sure that I used most recent compiled gcc

$ gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /home/user/gcc/gcc-10.3.1-20210422/gcc-10.3.1-20210422/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr/local/gcc-10.3.1-1-final --program-suffix=10.3.1-1-final --enable-languages=c,c++ --disable-multilib --disable-libstdcxx-pch --enable-libstdcxx --with-system-zlib --enable-shared
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 20210422 (GCC) 

from the gcc.spec

* Thu Apr 22 2021 Jakub Jelinek <jakub@redhat.com> 10.3.1-1
- update from releases/gcc-10 branch

So, is there any ugly workaround to hack version label, since I can’t make it work with IGNORE_CC_MISMATCH=1 flag, either?

I’m trying to understand what you are doing.
You have a tool that you know is broken, but you insist on using it.
This I do not understand.

I have in a separate thread given details about how to update
apt-cacher-ng to minimise the errors when working with Fedora
repositories, including the updates repositories.
If you follow that thread you will be able to have a working cacher for
Fedora before I release an updated package.

In the meantime, you can not use cacher for a Fedora template (or a
standalone) , use the --releasever option to hone in on the release that
you need and then download the package.

1 Like

I downloaded the source gcc-10.3.1-1.fc32.src.rpm and compiled gcc from it. Installed it and used it to build drivers. It doesn’t work.
It says it is

10.3.1 20210422

and that I need

10.3.1 20210422 (Red Hat 10.3.1-1)

That’s what is written above.

i have no idea what is going on with this specific gcc version being asked for.

Almost a week ago I told you what package to install, and told you
that it provided exactly the version string you require.
I gave you the exact command to run.

1 Like

Yes you did, but it looks you don’t receive replies via email.

This is what I wrote above. When I tried to install it with gcc-12.x present, it complains on version and a ton of other conflicts. When I removed gcc-12.x and tried to install it, it asked to remove tons of packages and downgrade the rest of the template to unrecognizability so most probably it wouldn’t boot.

That is why I compiled it instead and installed it as an additional version, which is eventually not the one asked for.

If something is wrong with the procedure I took, please let me know.