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.