# cat /etc/redhat-release Red Hat Enterprise Linux release 8.9 Beta (Ootpa) # rpm -q binutils gcc-toolset-13-binutils package binutils is not installed # dnf install -y gcc-toolset-13-binutils [...] # ld -bash: /usr/bin/ld: No such file or directory That's expected. But: # dnf install -y binutils [...] the primary link for ld must be /opt/rh/gcc-toolset-13/root/usr/bin/ld the primary link for ld must be /opt/rh/gcc-toolset-13/root/usr/bin/ld # ld -bash: /usr/bin/ld: No such file or directory is not.
I think that this is happening because the gcc-toolset-13-binutils spec file is using the system version of the "alternatives" script, rather than the GTS-13 version. ie https://bugzilla.redhat.com/show_bug.cgi?id=2209148 But that should have been fixed by the gcc-toolset-13-binutils-2.40-8.el9 build, so I need to investigate further.
OK, so it is the alternatives system which is generating this message, but I am not sure exactly what it means or how to fix it. Oh, and the "fixed" binutils build for BZ 2209148 is being used, so it may be that the fix for that BZ is actually wrong...
The problem exists if you perform the opposite installation sequence too: # dnf install -y binutils [...] # dnf install -y gcc-toolset-13-binutils [...] the primary link for ld must be /usr/bin/ld the primary link for ld must be /usr/bin/ld [...] # /opt/rh/gcc-toolset-13/root/usr/bin/ld sh: /opt/rh/gcc-toolset-13/root/usr/bin/ld: No such file or directory Still investigating.
Should be fixed by: gcc-toolset-13-binutils-2.40-11.el8 The problem - I think - is that the gcc-toolset-13-binutils needs to use the alternatives script with the --altdir and --admindir options set to point to the gts-13 equivalents. Then it will not interfere with the alternatives used by the system binutils.
Verified with gcc-toolset-13-binutils-2.40-11.el8.