#1023690 gcc-11 should not be shipped in trixie

Package:
gcc-11
Source:
gcc-11
Description:
GNU C compiler
Submitter:
Adrian Bunk
Date:
2025-09-04 17:07:01 UTC
Severity:
normal
Tags:
#1023690#5
Date:
2022-11-08 19:18:06 UTC
From:
To:
gcc-11 should not be shipped in bookworm.
#1023690#24
Date:
2023-02-05 14:31:43 UTC
From:
To:
Maybe it is okay for the gcc-11 packages that cannot move to gcc-12 to go back to gcc-10?
I guess, gcc-10 is not as easy to get out because of the gcc-plugin and gnat stuff that is
not replaceable by gcc-11 or gcc-12. Then we can aim for gcc-10 and gcc-12 in bookworm.
#1023690#29
Date:
2023-02-05 14:41:45 UTC
From:
To:
The complete list of packages in bookworm still using gcc-10 is:
- grub2
- shim
- simde (fixed in unstable)

cu
Adrian
#1023690#42
Date:
2025-01-02 18:04:13 UTC
From:
To:
It appears that nothing besides the gcc-11-cross* packages
(Build-)Depends on gcc-11 in trixie and unstable. I guess we should
reassign the bug to ftp.debian.org for package removal?

Regards
Aurelien
#1023690#47
Date:
2025-01-02 18:37:44 UTC
From:
To:
please keep it still in unstable, it's already removed in testing.
#1023690#52
Date:
2025-01-02 18:51:23 UTC
From:
To:
Do we really need to keep 6 GCC versions in the archive?

Regards
Aurelien
#1023690#57
Date:
2025-01-02 18:54:04 UTC
From:
To:
does it personally hurt you?

11 and 12 are the versions which were shipped in stable, and apparently
people still use these packages for backports.
#1023690#64
Date:
2025-08-20 07:26:15 UTC
From:
To:
Hi Matthias,

Versions 11 and 12 (predating gcc-for-host) include a lot of
cross-architecture undeclared file conflicts. Doing archive wide
conflict analysis is dominated by these two packages and poses a
significant additional cost on that work.

Yes, just keeping them poses a cost. Now it s up to you and me how to
deal with that. I see three possible routes forward:

 * Delete them from the archive
 * Fix the undeclared file conflicts
 * Exclude them from conflict analysis

I hope you can see how I find the first option most attractive, but then
I'm probably missing parts of the bigger picture.

Helmut
#1023690#69
Date:
2025-09-01 05:49:51 UTC
From:
To:
it's too early for the first solution.  We still need 11 for
bootstrapping libgphobos on ppc64el, and we need to address the issue
about a "stable" compiler for shim.

Matthias
#1023690#74
Date:
2025-09-01 06:07:24 UTC
From:
To:
Hi Matthias,

I was not aware of the ppc64el aspect and expecting the shim part. Do
note that opinions on the bootstrapping aspect vary. In theory, we'd
need every major version of rustc to bootstrap rustc as each of them
requires the previous one. Yet, that's not what we're doing. We'd also
need gcc-4.0 in principle as that could be built without a C++ compiler.
There may be other compromises here, but implementing them may not be
worth the effort.

How about deleting gcc-11 and gcc-12 based cross toolchains but keeping
the native ones then? Do we need either of those cross toolchains for
the aforementioned use cases? Removing them without also removing gcc-11
and gcc-12 would be sufficient to make most of the undeclared file
conflicts go away.

Helmut
#1023690#79
Date:
2025-09-04 17:06:07 UTC
From:
To:
Hi,

For shim considering an old compiler as stable might be a mistake.
Indeed a new version of binutils can change the binary output (see for
example the x86 NOP changes that broke valgrind in binutils 2.42), and
we might be forced to do GCC even in stable for security reason (see for
instance gcc-12 12.2.0-14+deb12u1 even if that version had no impact on
shim).

IMHO, the best way to have a stable compiler would be to pickup an
upstream binutils and gcc version, include them at part of the shim
sources and build them with the package. Building a simple binutils and
GCC, for only the C and C++ backends, without bootstrap and without
profile builds is relatively fast and should be sufficient.

Regards
Aurelien