The solution to this problem is here https://salsa.debian.org/rpavlik/gcc-10-compat
From the site:
There are a number of bugs filed for this - the one I have submitted this info to is https://bugs.debian.org/972820.
This is an apparent bug with the gcc-10 packages in Debian: they renamed several packages and removed the transitional packages after Buster and before the release of Bullseye. The following packages were renamed (to match stated convention/debian policy more closely, I think):
* libgcc1 -> libgcc-s1
* lib64gcc1 -> lib64gcc-s1 (on 32 bit architectures only)
* lib32gcc1 -> lib32gcc-s1 (on 64 bit architectures only)
* libx32gcc1 -> libx32gcc-s1 (on x86_64 only)
* a few others on less common arches
The newly-renamed packages have a `Provides: libgcc1` (etc.) property, but it appears that apt is preferring a real (old) libgcc1 package over a virtual package that is only "provide"d by the newer package, since it's trying to not break your system. I am not familiar with the details of the internals of dependency resolution and installation order, but that's how I understand the problem anyway. This repo provides a "real" libgcc1, etc. package to get apt over that hurdle.
In general you know you've hit this bug when you see this on trying to do a dist-upgrade from buster to bullseye (or equivalent in derived distros):
The following packages have unmet dependencies:
libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
Just tried updating my Librem 13 V2, this still is not fixed upstream in Debian, or in Librem repos. But this got me back on track.