You're not supposed to invoke /opt/rh/gcc-toolset-11/root/usr/bin/g++ directly; please use the scl wrapper which sets the correct paths.

Then why it works for almost everything else? And it worked fine in RHEL7?
For example just remove -g and it would work fine.

I'm trying to use this compiler from really complicated cmake based build system, so if the compiler just works without wrappers it would make things a lot easier.
And I know that it is possible thing to do, gcc-toolset-11's behaviour is a regression. If you're interested I can tell you which version broke it. :)
I think devtoolset-11 works just fine on RHEL7 (not at the machine at the moment to test it), so it is not a change in the compiler that breaks it, its the gcc-toolset magic that has changed somehow.

This is weird.  On RHEL7 we invoke as using an absolute path:
/opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/as -v --gdwarf-4 --64 -o /tmp/ccNc0s3g.o /tmp/cczag1QK.s
but on RHEL8:
as -v --gdwarf-4 --64 -o /tmp/ccVk1z9s.o /tmp/cczlheMY.s

I don't see anything in the gcc spec file that would explain the difference.  This happens with gcc-toolset-9 as well.

Running
/opt/rh/gcc-toolset-12/root/usr/bin/gcc -g x.c
works even though the system as is used because --gdwarf-4 isn't passed to as.

I can make several guesses about the root cause:
1. There is a difference in some patch that you apply.
2. There is a configure test which has different result on RHEL7 and RHEL8.
3. There is a difference in the common environment setup between the two OSes.

Given this new information would you reclassify this as an actual bug, so it can be resolved?

Gah.  The problem is trivial -- we're not shipping certain symlinks on RHEL8+:

%if 0%{?scl:1}
%if 0%{?rhel} <= 7 
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/ar
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/as
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/ld
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/ld.bfd
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/ld.gold
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/nm
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/objcopy
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/ranlib
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}/strip
%endif
%endif

I'm going to fix this in GTS 12.1; I don't think it's intentional that the symlinks are missing on RHEL8.

Sorry for closing the BZ prematurely.

Is there any chance to fix this in gcc-toolset-11?
I actually need to use this particular compiler, because I need to build software that conforms to vfxplatform CY2023 (https://vfxplatform.com/).

Thanks.

(In reply to Teodor Petrov from comment #7)
> Is there any chance to fix this in gcc-toolset-11?
> I actually need to use this particular compiler, because I need to build
> software that conforms to vfxplatform CY2023 (https://vfxplatform.com/).
> 
> Thanks.

Sorry, I couldn't justify making an update for GTS 11 at this point.  Especially since this usage is technically unsupported.
As a workaround, you could probably create the symlinks by yourself, or adjust PATH.  Sorry.

OK. I'll handle this locally somehow.
Do you have a public git/svn/cvs repo where you maintain the SPEC files for these packages?

(In reply to Teodor Petrov from comment #9)
> OK. I'll handle this locally somehow.

Thanks.

> Do you have a public git/svn/cvs repo where you maintain the SPEC files for
> these packages?

Yeah, I think you can take a look at it in gitlab:
https://gitlab.com/redhat/centos-stream/rpms/gcc/-/tree/scl-gcc-toolset-12-rhel-9.2.0

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (gcc-toolset-12-gcc bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2766