+++ This bug was initially created as a clone of Bug #2162498 +++

Description of problem:
In RHEL/CentOS 7 calling /opt/rh/devtoolset-x/root/usr/bin/g++ worked just fine.
It seems this is not the case with g++ from gcc-toolset-11 on RHEL8 (Rocky Linux 8.7 in particular).
It seems that the correct version of `as` is expected to be in path and g++ is not using an absolute path as before.

Version-Release number of selected component (if applicable):

$ rpm -qa | grep gcc-tool
gcc-toolset-11-libstdc++-devel-11.2.1-9.1.el8.x86_64
gcc-toolset-11-binutils-2.36.1-2.el8.x86_64
gcc-toolset-11-gcc-11.2.1-9.1.el8.x86_64
gcc-toolset-11-runtime-11.1-1.el8.x86_64
gcc-toolset-11-gcc-c++-11.2.1-9.1.el8.x86_64
$ cat /etc/redhat-release 
Rocky Linux release 8.7 (Green Obsidian)

How reproducible:

Steps to Reproduce:
1. create /tmp/main.cpp, hello world is fine
2. /opt/rh/gcc-toolset-11/root/usr/bin/g++ -g -o /tmp/main /tmp/main.cpp

Actual results:
$ /opt/rh/gcc-toolset-11/root/usr/bin/g++ -o /tmp/main /tmp/main.cpp  -g
as: unrecognized option '--gdwarf-4'

Expected results:
Just working and producing executable.
If you repeat the steps but add 'scl enable gcc-toolset-11 bash' before calling the compiler it works as expected.

--- Additional comment from Marek Polacek on 2023-01-19 18:07:35 UTC ---

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.

--- Additional comment from Teodor Petrov on 2023-01-19 18:22:41 UTC ---

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.

--- Additional comment from Marek Polacek on 2023-01-19 23:16:09 UTC ---

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.

--- Additional comment from Teodor Petrov on 2023-01-20 09:25:29 UTC ---

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?

--- Additional comment from Marek Polacek on 2023-01-24 23:45:10 UTC ---

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.

--- Additional comment from RHEL Program Management on 2023-01-24 23:45:21 UTC ---

This bug was reopened or transitioned from a non-RHEL to RHEL product.  The stale date has been reset to +6 months.