You can get a list of packages that provide filename with:
dnf provides */libsupc++.a
(dnf naturally seeks only from the enabled repositories.)
AlmaLinux 9 seems to have /usr/lib/gcc/x86_64-redhat-linux/11/32/libsupc++.a
in gcc-c++-11.4.1-3.el9.alma.1.x86_64
and the /usr/lib/gcc/{i686,x86_64}-redhat-linux/11/libsupc++.a
in libstdc++-static-11.4.1-3.el9.alma.1.{i686,x86_64}
The GCC Toolsets continue the Red Hat Software Collections (SCL) setup, where one can:
[jlehtone@al9 ~]$ which gcc
/usr/bin/gcc
[jlehtone@al9 ~]$ scl enable gcc-toolset-13 bash
[jlehtone@al9 ~]$ which gcc
/opt/rh/gcc-toolset-13/root/usr/bin/gcc
[jlehtone@al9 ~]$ exit
exit
[jlehtone@al9 ~]$ which gcc
/usr/bin/gcc
That is, the scl command starts a process (bash in the example above) with environment modified by /opt/rh/${XXX}/enable files (XXX=gcc-toolset-13 in the example). See man scl.
(The scl load calls module from environment-modules.)
Binaries built within environment can be run without the environment. The idea of SCL (introduced for RHEL 7 and 6) was to be able to install more than one version simultaneously (without unique filenames). RHEL 8 introduced application streams that do not allow simultaneous install and use, but the GCC Toolset continues with SCL idiom.
All distros I’ve looked have an i686 version of the library but do not have x86_64 libraries, except for Fedora and old Centos 8, which do have both (and the gcc toolset environments).
I would suspect that this breaks some RPM builds, but I guess this is not the case. The supc++ library is a static version of libstdc++ which does not have the stl containers, only the c++ language (exception) support. It is useful because you do not need libstdc++.so at runtime, only libc.