View Issue Details

IDProjectCategoryView StatusLast Update
0000113Rocky-Linux-8clangpublic2022-06-02 18:28
ReporterJason Vas Dias Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status newResolutionopen 
Summary0000113: upgrade to clang 13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 broke building due to no LD_LIBRARY_PATH and no -lgcc_s resolved
DescriptionBefore upgrade to 13.0.1-1.module+el8.6.0+825+7e27476a.x86_64 with recent 'yum update'
on my x86_64 :
 $ grep ROCKY /etc/os-release
ROCKY_SUPPORT_PRODUCT="Rocky Linux"
ROCKY_SUPPORT_PRODUCT_VERSION="8"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8"


I was able to build with the system clang OK , without any LD_LIBRARY_PATH setting.

Now , after upgrade, I cannot, because its spec file seems to be incorrectly
configured to NOT include the correct /usr/lib/gcc/x86_64-redhat-linux/8/ path to pick up libgcc_s.so .

Please correct - now I have to temporarily modify all of our build environments to set LD_LIBRARY_PATH ,
I did not have to do this before.

<code>

$ echo '#include <stdio.h>
int main( int argc, char *const *argv, char *const *envp )
{ printf( "hello, world!\n" );
> return 0;
> }
> ' > t.c
$ clang -o t t.c
/usr/bin/ld: cannot find -lgcc_s
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
$ echo '#include <stdio.h>
int main( int argc, char *const *argv, char *const *envp )
{ printf( "hello, world!\n" );
> return 0;
> }
> ' > t.c
$ clang -o t t.c
/usr/bin/ld: cannot find -lgcc_s
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

</code>
TagsNo tags attached.

Activities

Jason Vas Dias

Jason Vas Dias

2022-06-01 16:36

reporter   ~0000201

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 .
Louis Abel

Louis Abel

2022-06-01 16:40

administrator   ~0000202

Last edited: 2022-06-01 16:42

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!
Jason Vas Dias

Jason Vas Dias

2022-06-01 16:47

reporter   ~0000203

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.
Jason Vas Dias

Jason Vas Dias

2022-06-01 16:50

reporter   ~0000204

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 ...
Jason Vas Dias

Jason Vas Dias

2022-06-01 16:53

reporter   ~0000205

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)
Neil Hanlon

Neil Hanlon

2022-06-01 16:55

administrator   ~0000206

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
```
Louis Abel

Louis Abel

2022-06-01 17:01

administrator   ~0000207

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
Jason Vas Dias

Jason Vas Dias

2022-06-01 17:03

reporter   ~0000208

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
Jason Vas Dias

Jason Vas Dias

2022-06-01 17:07

reporter   ~0000209

Actually, correction, the 'cross-gcc' build only provides libgcc.a, not libgcc_s.so at all (it is for Embedded environments) .
Jason Vas Dias

Jason Vas Dias

2022-06-01 17:08

reporter   ~0000210

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 .
Jason Vas Dias

Jason Vas Dias

2022-06-01 17:09

reporter   ~0000211

And this bug is really that the OLD clang DID handle this situation correctly, and now the new one does not .
Jason Vas Dias

Jason Vas Dias

2022-06-01 17:48

reporter   ~0000212

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/ .
Jason Vas Dias

Jason Vas Dias

2022-06-01 23:07

reporter   ~0000213

( 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 !
Jason Vas Dias

Jason Vas Dias

2022-06-02 00:29

reporter   ~0000214

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 ...
Louis Abel

Louis Abel

2022-06-02 18:28

administrator   ~0000216

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.

Issue History

Date Modified Username Field Change
2022-06-01 16:29 Jason Vas Dias New Issue
2022-06-01 16:36 Jason Vas Dias Note Added: 0000201
2022-06-01 16:40 Louis Abel Note Added: 0000202
2022-06-01 16:42 Louis Abel Note Edited: 0000202
2022-06-01 16:47 Jason Vas Dias Note Added: 0000203
2022-06-01 16:50 Jason Vas Dias Note Added: 0000204
2022-06-01 16:53 Jason Vas Dias Note Added: 0000205
2022-06-01 16:55 Neil Hanlon Note Added: 0000206
2022-06-01 17:01 Louis Abel Note Added: 0000207
2022-06-01 17:03 Jason Vas Dias Note Added: 0000208
2022-06-01 17:07 Jason Vas Dias Note Added: 0000209
2022-06-01 17:08 Jason Vas Dias Note Added: 0000210
2022-06-01 17:09 Jason Vas Dias Note Added: 0000211
2022-06-01 17:48 Jason Vas Dias Note Added: 0000212
2022-06-01 23:07 Jason Vas Dias Note Added: 0000213
2022-06-02 00:29 Jason Vas Dias Note Added: 0000214
2022-06-02 18:28 Louis Abel Note Added: 0000216