Where can I obtain this specific gcc version

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:

https://fedoraproject.org/wiki/Packaging:Naming#Separators

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:
dnf install PACKAGE-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

3 Likes

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.

Then:

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

OK

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

Profit.

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
https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/32/Everything/SRPMS/Packages/g/

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.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.1-1-final/libexec/gcc/x86_64-pc-linux-gnu/10.3.1/lto-wrapper
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

%changelog
* 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.

The obvious thing that is wrong is that you have compiled from source
but you have not set the version name to the one that you want.
You should look at the --with-pkgversion configuration option.

But why are you doing this?
You can use the power of Qubes to install a template that will allow you
to install and use the native package (and now you know exactly what that
package is, and what Fedora version to use). This has the advantage
that you will be building on the same platform where you want to use
the modules, and you’ll avoid any version conflicts.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

I tried with

--with-pkgversion='10.3.1 20210422 (Red Hat 10.3.1-1)'

only compiling to fail with:

configure: error: C compiler cannot create executables

for the first time ever, and the only thing I changed in a procedure was adding that flag.

I gave up.

I just think packages like gcc version above, used to build Qubes OS should be available in qubes repos. It’s not that hard to collect them at the time of building Qubes and to offer them to the users who will try in 7-10 years to build something, between fedora-3x and fedora 4x version on which two versions Qubes OS’s dom0 is/will be based on. Trivial.

I don’t think I am power enough to follow this, but if you mean by this to use native kernel in a template VM, I am aware of that on the other topic.

But - if I rely on Qubes, I want to rely on each part of it. For example, dkms in a template to work with the kernel provided by dom0. So, this is what I expect - developing Qubes to work with this, not to rely on distro kernels. I didn’t choose Qubes for that.

I want to build on the same platform where I want to use modules - in a kernel provided by Qubes devs.

So, do the devs think it is not important enough dkms to work in their kernels?

The packages are available, as I have explained to you.
Why would Qubes provide them when they are available from the source,
in this case Fedora.

I do not understand you.
You rely on Fedora for many things in Qubes.

I do not understand. dkms will work with Qubes provided kernels. I
also have dkms working with native kernels.
You should not extrapolate from your own failure to get this working,
particularly when you have seemed to ignore advice given.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

How? I’m still waiting for that answer, obviously no one wanted to provide me with…

You shouldn’t extrapolate that it works because it’s only me who’s reporting it doesn’t work.

You already asked me if I followed your thoughts. I have already answered that I did to the extent I was able to. Beside ignorance is different than ignoring, I am sure that you are aware that you are not easy to follow (unlike @rustybird for example). I’m not talking about knowledge here, but about the ability/will to transfer it.

I believe you have linked to a GitHub issue which was closed because the
user was able to use dkms on all kernels from current-testing.
I’m not sure what your point is.

Hmm. If I am asking for help it does not look like a smart move to be rude
to someone who is trying to help.

The issue you have is not Qubes specific.
In Qubes, it should be easy for you to get the specific gcc version
you want, and I have tried to help you do this.
I tried to help you build your own gcc with the description you wanted,
but you were not able to do this.
In various sources, you can see workarounds for dealing with version
mismatches - you don’t say if you have tried these.

I have a feeling that you need to step back and make sure that you are
asking the right question. (XY problem)

I have little time free, and for various reasons it is difficult for me
to send detailed instructions or handhold users. I do what I can.
Also, of course, you are a novice, and these matters are only available
to Knights of St Andrew, or those of a higher degree.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

If I was to suggest one thing, that would be a lesser use of epithets and verbs which lead to labeling people. Emphasizing that someone is “confused”, “ignoring”, “not thinking”, “novice”, “lesser degree”, and many other doesn’t help establishing friendly environment. On the contrary, it might make a sense of passive aggressiveness. I don’t see such an attitude from other “Knights of St Qubes”.

Thanks for your time. I agree it’s often wasted here.

Some changes to my Kill File should help reduce that wasted time.