 |
Even as root, after installing the clang-devel, glibc-devel , lots of *-devel packages, and having worked fine before upgrade, even as root it still fails : [root@dl180 tmp]# clang -o t t.c /bin/ld: cannot find -lgcc_s clang-13: error: linker command failed with exit code 1 (use -v to see invocation) I will be reverting to clang-12 . |
 |
https://git.rockylinux.org/staging/rpms/clang/-/commit/42c3f5b3c34c2daab912b8c29303719b369b5d82 - This is the commit that rebased the clang version. I don't see anything related to what you've stated in the spec file as a difference between the two. With that being said, I cannot reproduce your issue. [root@awx tmp]# rpm -q clang clang-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 [root@awx tmp]# cat t.c #include <stdio.h> int main( int argc, char *const *argv, char *const *envp ) { printf( "hello, world!\n" ); return 0;} [root@awx tmp]# clang -o t t.c [root@awx tmp]# ./t hello, world! |
|
|
N.B. : it is also a bug to ship a system compiler that requires a LD_LIBRARY_PATH setting or /etc/ld.so.conf.d/ file change in order to work to compile 'hello_world.c' . If it requires such a change, it's RPM spec file needs to be changed to make the necessary changes to an /etc/ld.so.conf.d/ file on install, or to change its compiler spec file to not require the effective ld.so(2) LD PATH setting to be changed ( the better option - like old clang did ). We thought Rocky would be a stable platform for our build server : evidently not. We'll have to look at building our own system Clang + LLVM + GCC installation and setting their RPM epochs to something beyond what Rocky can provide because of this issue ; the system Clang you provide evidently received no testing for users upgrading from previous latest clang version. |
|
|
Aha, thanks Louis ! I had not seen your comment yet. That is strange. I have NO LD_LIBRARY_PATH setting, I am the only root user on the machine, my /etc/ld.so.conf.d/* files have not changed since before upgrade, before the upgrade I was able to run Clang fine, now I can't - I am at a loss to explain why not ATM ... |
|
|
And by 'spec' file in first comment I meant compiler spec file, as in output of 'gcc -dumpspecs' . ie. the clang compiler does not seem to be picking up the location of '-lgcc_s' without a LD_LIBRARY_PATH setting . [root@dl180 tmp]# clang --verbose -o t t.c clang version 13.0.1 (Red Hat 13.0.1-1.module+el8.6.0+825+7e27476a) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /bin Found candidate GCC installation: /bin/../lib/gcc/i686-redhat-linux/8 Found candidate GCC installation: /bin/../lib/gcc/x86_64-linux-gnu/11 Found candidate GCC installation: /bin/../lib/gcc/x86_64-redhat-linux/8 Selected GCC installation: /bin/../lib/gcc/x86_64-linux-gnu/11 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/clang-13" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name t.c -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/tmp -resource-dir /usr/lib64/clang/13.0.1 -internal-isystem /usr/lib64/clang/13.0.1/include -internal-isystem /usr/local/include -internal-isystem /bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/tmp -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/t-10c06a.o -x c t.c clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/local/include /usr/include End of search list. "/bin/ld" --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o t /bin/../lib/gcc/x86_64-linux-gnu/11/../../../../lib64/crt1.o /bin/../lib/gcc/x86_64-linux-gnu/11/../../../../lib64/crti.o /bin/../lib/gcc/x86_64-linux-gnu/11/crtbegin.o -L/bin/../lib/gcc/x86_64-linux-gnu/11 -L/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib -L/lib -L/usr/lib /tmp/t-10c06a.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /bin/../lib/gcc/x86_64-linux-gnu/11/crtend.o /bin/../lib/gcc/x86_64-linux-gnu/11/../../../../lib64/crtn.o /bin/ld: cannot find -lgcc_s clang-13: error: linker command failed with exit code 1 (use -v to see invocation) |
 |
for comparison, from a bare container with just clang installed: ``` [root@9c9aa22e7cd0 /]# clang --verbose -o t t.c clang version 13.0.1 (Red Hat 13.0.1-1.module+el8.6.0+825+7e27476a) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/clang-13" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name t.c -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/ -resource-dir /usr/lib64/clang/13.0.1 -internal-isystem /usr/lib64/clang/13.0.1/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/ -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/t-6f4d59.o -x c t.c clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/local/include /usr/include End of search list. "/usr/bin/ld" --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o t /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o /usr/bin/../lib/gcc/x86_64-redhat-linux/8/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-redhat-linux/8 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib -L/lib -L/usr/lib /tmp/t-6f4d59.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-redhat-linux/8/crtend.o /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o ``` |
|
|
I'm noticing in your output that you have gcc 8 and 11 installed. How did you install 11? See below, I'm only pulling and using gcc 8. [root@awx tmp]# clang --verbose -o t t.c clang version 13.0.1 (Red Hat 13.0.1-1.module+el8.6.0+825+7e27476a) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 "/usr/bin/clang-13" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name t.c -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/root -resource-dir /usr/lib64/clang/13.0.1 -internal-isystem /usr/lib64/clang/13.0.1/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/root -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/t-5540d7.o -x c t.c clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib64/clang/13.0.1/include /usr/local/include /usr/include End of search list. "/usr/bin/ld" --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o t /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o /usr/bin/../lib/gcc/x86_64-redhat-linux/8/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-redhat-linux/8 -L/usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib -L/lib -L/usr/lib /tmp/t-5540d7.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-redhat-linux/8/crtend.o /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o |
|
|
Aha, this is why : [root@dl180 gcc]# find /usr/lib/gcc/ -name 'libgcc_s*' /usr/lib/gcc/x86_64-redhat-linux/8/32/libgcc_s.so /usr/lib/gcc/x86_64-redhat-linux/8/libgcc_s.so [root@dl180 gcc]# And clang says: Selected GCC installation: /bin/../lib/gcc/x86_64-linux-gnu/11 which was from MY build of the EPEL 'cross-gcc' SRPM , to build latest GCC version for ALL supported targets (including PPC64, AARCH64 .. etc). This does include a build of GCC 11 for x86_64, which does NOT install libgcc_s in its compiler library directory, but DOES install it in /usr/local/lib64 . So I just need to create the link OK in its /usr/lib directory . But actually, the OLD clang worked FINE in this situation, it appears the NEW clang does not . So I do have |
|
|
Actually, correction, the 'cross-gcc' build only provides libgcc.a, not libgcc_s.so at all (it is for Embedded environments) . |
|
|
So, what clang SHOULD be doing, when it Chooses a GCC implementation, is actually VERIFY that the gcc directory actually does contain 'libgcc_s.so' , as a valid link to a valid libgcc_s.so.1 file . |
|
|
And this bug is really that the OLD clang DID handle this situation correctly, and now the new one does not . |
|
|
OK, I now need to re-build the "big daddy" 'gcc-cross' Umbrella RPM, release '-2', with gcc-11 (NOW gcc v11.2.1-9) which built last time : [root@dl180 x86_64]# ls gcc* gcc-aarch64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-ppc64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-alpha-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-riscv64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-arc-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-s390x-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-arm-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-sparc64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-avr32-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-tile-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-bfin-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-x86_64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c6x-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-xtensa-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-aarch64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-frv-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-alpha-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-h8300-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-arc-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-hppa64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-arm-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-hppa-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-avr32-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-ia64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-bfin-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-m32r-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-c6x-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-m68k-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-frv-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-microblaze-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-h8300-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-mips64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-hppa64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-mn10300-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-hppa-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-nios2-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-ia64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-openrisc-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-m32r-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-powerpc64le-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-m68k-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-powerpc64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-microblaze-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-ppc64le-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-mips64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-ppc64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-mn10300-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-riscv64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-nios2-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-s390x-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-openrisc-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-sparc64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-powerpc64le-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-tile-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-powerpc64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-x86_64-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-c++-ppc64le-linux-gnu-11.2.1-1.el8.x86_64.rpm gcc-xtensa-linux-gnu-11.2.1-1.el8.x86_64.rpm I will first have to build & install the new cross-binutils RPM , and also we build glibc with '-mtune=native' , and to disable spectre & meltdown syscall trampolines, and we run the kernel with boot args to disable spectre & meltdown mitigations ( we are on a very secure but 10-year old x86_64 8-core system ). Note I also have installed: [root@dl180 x86_64]# rpm -qa 'gcc-toolset-9-gcc-*' 'gcc-toolset-[1][01]-gcc-*' gcc-toolset-10-gcc-c++-10.3.1-1.2.el8_5.x86_64 gcc-toolset-9-gcc-gdb-plugin-9.2.1-2.3.el8.x86_64 gcc-toolset-11-gcc-c++-11.2.1-9.1.el8.x86_64 gcc-toolset-9-gcc-gfortran-9.2.1-2.3.el8.x86_64 gcc-toolset-11-gcc-gfortran-11.2.1-9.1.el8.x86_64 gcc-toolset-11-gcc-gdb-plugin-11.2.1-9.1.el8.x86_64 gcc-toolset-10-gcc-gdb-plugin-10.3.1-1.2.el8_5.x86_64 gcc-toolset-10-gcc-gfortran-10.3.1-1.2.el8_5.x86_64 gcc-toolset-9-gcc-c++-9.2.1-2.3.el8.x86_64 [root@dl180 x86_64]# rpm -qa 'clang*' 'llvm*' clang-devel-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 llvm-libs-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 clang-resource-filesystem-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 clang-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 clang-tools-extra-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 llvm-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 clang-libs-13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 So my 'gcc-cross' Umbrella RPM gets built with the gcc-toolset-11-gcc gcc11, which has ITS libgcc_s.so , in : [root@dl180 x86_64]# ls -l /opt/rh/gcc-toolset-11/root/usr/lib/gcc/x86_64-redhat-linux/11/libgcc_s.so -rw-r--r--. 1 root root 195 Apr 18 04:07 /opt/rh/gcc-toolset-11/root/usr/lib/gcc/x86_64-redhat-linux/11/libgcc_s.so which is the one we want to pick up, IFF we were trying to use the Embedded x86_64 gcc-cross compiler, which we are NOT, because that is the libgcc_s.so that the compiler in /usr/lib/gcc/x86-64-linux-gnu/11 was (will be) built against. But my reason for raising this bug still stands : o the old clang version did NOT have a problem with /usr/lib/gcc/x86-64-linux/gnu/11 existing , but now the new one does, despite that it should know better that it is looking for libgcc_s.so and not finding it in that directory . I will try to fix that in the clang spec file and possibly with a patch, while my big cross-gcc build is building , and will post a patch back here when done. Users OUGHT to be able to install other compilers, which are for embedded builds and do NOT have libgcc_s.so installed, such as are produced by the build of the EPEL 'crosss-gcc' SRPM , and are shipped by Rocky in the gcc-toolset-* RPMs, without this effecting in any way the behaviour of a "system" compiler like /usr/bin/clang, which OUGHT to be HARDCODED to ONLY look for libgcc_s.so in the SYSTEM COMPILER directory, ../lib/gcc/x86-64-redhat-linux/8/ . |
|
|
( that is , after building latest gmp, mpfr, isl, cloog-isl, etc, into /usr/local/{lib64,include} ) . The key is that ONLY if I actually do set LD_LIBRARY_PATH=/opt/rh/gcc-toolset-11/root/usr/lib/gcc/x86_64-redhat-linux/11:/usr/local/lib64 do I want the gcc or any of its components from gcc-toolset-11 , or the Embedded x86_64 build of GCC, to work - THEY MUST NOT WORK UNLESS they have this effective LD_LIBRARY_PATH setting. OK , I have achieved this. But I still ought to be able to run system compilers, like /usr/bin/gcc or /usr/bin/clang , WITHOUT ANY LD_LIBRARY_PATH setting, and they should NOT attempt to use OPTIONAL EXTRAS like the cross-gcc embedded or gcc-toolset-11 compilers in any way if they DO NOT have these paths in LD_LIBRARY_PATH or in a configured /etc/ld.so.conf.d/* file . So this is what I am doing . I am slowly working my way through your latest kernel build, ( to build with spectre&meltdown mitigations disabled ) then I will build cross-binutils, and again the new gmp, mpfr, isl, cloog-isl , readline, ncurses, flex, bison , et al into /usr/local , with the new compiler against the -mtune=native non-spectre-mitigation-enabled glibc , and then cross-binutils, coreutils, et al, and then cross-gcc - what fun ! OK, the above is nothing to do with Rocky, of course, but please Rocky , enable other compilers to install their /usr/lib/gcc/$X directory WITHOUT affecting system compilers like /usr/bin/gcc , /usr/bin/clang ! |
|
|
Why couldn't you have kept the system Clang at Clang 12, and then provided a clang-toolset-13 and clang-toolset-14 package, like you did for gcc ? Why, if cross-binutils and cross-gcc is installed, do not the LLVM and Clang SRPMs then build for ALL platforms that they can build for , not just a small subset ( ie. , produce a cross-clang Umbrella RPM ) ? I think that to me looks like the best solution . This is what I will do, then , and submit results here . So , I am firstly going to replace {clang,llvm}-13* with their OLD clang-12 versions, then I am going to build new llvm-toolset-13 and clang-toolset-13 SRPMs I make from spec files I write (which will have higher EPOCHs than the Rocky clang packages) , then use those to produce llvm-toolset-14 and clang-toolset-14 - I will of course contribute these here once done. I suggest producing similar '*-toolset' or toolchain RPMs for GMP , ISL, MPFR, MPC , CLOOG, PPL, CLOOG-PPL, CLOOG-ISL at al (all of glibc, binutils and GCC + Clang + LLVM 's core dependencies ) - I then might as well go the whole hog and produce gcc-toolset-12 RPMs as well. A major RPM building session awaits ... |
|
|
We only ship what is provided by upstream. When we release new minor versions of our distribution, old versions are typically superseded by old versions. Clang is an example of this. gcc-toolset-* packages are SCL-type packages and operate differently from base packages and base modules. If you feel this is a major issue, I would highly suggest that you open a bug report at bugzilla.redhat.com. In majority of cases, we do not modify the sources that come from Red Hat to build the distribution. Clang and the rest of the llvm toolset are examples of such instances where we build what is shipped from Red Hat. |
|
|
Closing due to old bug report and we only ship the latest available from upstream. |
- Anonymous
