running different compiler than what's installed
I was wanting to run a different compiler than what's installed. I found the deps for gcc13 and downloaded them (deps): rpm -Uhv --test gcc13-13.1.1+git7364-1.1.x86_64.rpm warning: gcc13-13.1.1+git7364-1.1.x86_64.rpm: Header V3 RSA/SHA512 Signature, key ID 29b700a4: NOKEY error: Failed dependencies: cpp13 = 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libasan8 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libatomic1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libc.so.6(GLIBC_2.34)(64bit) is needed by gcc13-13.1.1+git7364-1.1.x86_64 libc.so.6(GLIBC_2.35)(64bit) is needed by gcc13-13.1.1+git7364-1.1.x86_64 libc.so.6(GLIBC_2.36)(64bit) is needed by gcc13-13.1.1+git7364-1.1.x86_64 libgcc_s1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libgomp1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libhwasan0 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libitm1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 liblsan0 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libtsan2 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libubsan1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 First I tried relocating the install path to my a devel dir '/home/devel/root' with rpm -relocate=/=/home/devel/root That didn't work as it said the package was not relocatable. Hmmm. Next I tried rpm2cpio and unpacking the cpio's under the root (using star). Set my LD_LIBRARY_PATH: export LD_LIBRARY_PATH=/home/devel/root/usr/lib64 for my test I just wanted to see gcc print its version. I set my PATH=/home/devel/root/usr/bin:$PATH When I tried running 'gcc --version', I got(get): /home/devel/root/usr/bin/gcc-13 --version gcc: symbol lookup error: /home/devel/root/usr/lib64/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE ----- Any ideas as to why this didn't work? Thanks! -linda
On 02.06.2023 06:08, L A Walsh wrote:
/home/devel/root/usr/bin/gcc-13 --version gcc: symbol lookup error: /home/devel/root/usr/lib64/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE
----- Any ideas as to why this didn't work?
bor@bor-Latitude-E5450:~$ nm -D /lib64/ld-linux-x86-64.so.2 | grep _dl_audit_symbind_alt 000000000001b750 T _dl_audit_symbind_alt@@GLIBC_PRIVATE bor@bor-Latitude-E5450:~$ You need ELF loader matching your glibc.
On 2023/06/01 20:55, Andrei Borzenkov wrote:
On 02.06.2023 06:08, L A Walsh wrote:
/home/devel/root/usr/bin/gcc-13 --version gcc: symbol lookup error: /home/devel/root/usr/lib64/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE
----- Any ideas as to why this didn't work?
bor@bor-Latitude-E5450:~$ nm -D /lib64/ld-linux-x86-64.so.2 | grep _dl_audit_symbind_alt 000000000001b750 T _dl_audit_symbind_alt@@GLIBC_PRIVATE bor@bor-Latitude-E5450:~$
You need ELF loader matching your glibc.
I see. Should glibc have a dependency on the ELF loader so it can pull in the right version? Thanks!
On 2023/06/02 05:10, Andrei Borzenkov wrote:
ELF loader (dynamic linker) is part of glibc.
But I had a modified path and ld_path, when I ran: /home/devel/root/usr/bin/gcc-13 --version
gcc: symbol lookup error: /home/devel/root/usr/lib64/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE ----- Any ideas as to why this didn't work?
bor@bor-Latitude-E5450:~$ nm -D /lib64/ld-linux-x86-64.so.2 | grep _dl_audit_symbind_alt 000000000001b750 T _dl_audit_symbind_alt@@GLIBC_PRIVATE bor@bor-Latitude-E5450:~$
You need ELF loader matching your glibc.
I had the glibc that 'gcc-13' depends on, so I would already have had the 'ld' for that glibc in /home/devel/root/usr/bin/ld, no? I.e. when I did 'gcc-13 --version', shouldn't the 'ld' from the glibc package have been picked up/used? FWIW, I'd done a rehash in bash. So still don't see why it didn't work.
On 02.06.2023 18:17, L A Walsh wrote:
On 2023/06/02 05:10, Andrei Borzenkov wrote:
ELF loader (dynamic linker) is part of glibc.
But I had a modified path and ld_path, when I ran:
Path to interpreter is hardcoded in ELF binary.
/home/devel/root/usr/bin/gcc-13 --version
gcc: symbol lookup error: /home/devel/root/usr/lib64/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE ----- Any ideas as to why this didn't work?
bor@bor-Latitude-E5450:~$ nm -D /lib64/ld-linux-x86-64.so.2 | grep _dl_audit_symbind_alt 000000000001b750 T _dl_audit_symbind_alt@@GLIBC_PRIVATE bor@bor-Latitude-E5450:~$
You need ELF loader matching your glibc.
I had the glibc that 'gcc-13' depends on, so I would already have had the 'ld' for that glibc in /home/devel/root/usr/bin/ld, no?
I.e. when I did 'gcc-13 --version', shouldn't the 'ld' from the glibc package have been picked up/used?
FWIW, I'd done a rehash in bash.
So still don't see why it didn't work.
On 6/2/23 12:38, L A Walsh wrote:
I was wanting to run a different compiler than what's installed.
I found the deps for gcc13 and downloaded them (deps): rpm -Uhv --test gcc13-13.1.1+git7364-1.1.x86_64.rpm warning: gcc13-13.1.1+git7364-1.1.x86_64.rpm: Header V3 RSA/SHA512 Signature, key ID 29b700a4: NOKEY error: Failed dependencies: cpp13 = 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libasan8 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libatomic1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libc.so.6(GLIBC_2.34)(64bit) is needed by gcc13-13.1.1+git7364-1.1.x86_64 libc.so.6(GLIBC_2.35)(64bit) is needed by gcc13-13.1.1+git7364-1.1.x86_64 libc.so.6(GLIBC_2.36)(64bit) is needed by gcc13-13.1.1+git7364-1.1.x86_64 libgcc_s1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libgomp1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libhwasan0 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libitm1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 liblsan0 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libtsan2 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64 libubsan1 >= 13.1.1+git7364-1.1 is needed by gcc13-13.1.1+git7364-1.1.x86_64
First I tried relocating the install path to my a devel dir '/home/devel/root' with rpm -relocate=/=/home/devel/root That didn't work as it said the package was not relocatable. Hmmm.
Next I tried rpm2cpio and unpacking the cpio's under the root (using star).
Set my LD_LIBRARY_PATH: export LD_LIBRARY_PATH=/home/devel/root/usr/lib64
for my test I just wanted to see gcc print its version.
I set my PATH=/home/devel/root/usr/bin:$PATH
When I tried running 'gcc --version', I got(get):
/home/devel/root/usr/bin/gcc-13 --version gcc: symbol lookup error: /home/devel/root/usr/lib64/libc.so.6: undefined symbol: _dl_audit_symbind_alt, version GLIBC_PRIVATE
----- Any ideas as to why this didn't work?
Not sure specifically, but it seems you are doing it a really hard way. The gcc13 package from [1] should be co installable with the system gcc. Once its installed all you should need to do is export CC and CXX to point to /usr/bin/gcc-13 before you run configure or meson or whatever tool your using to help build the software. 1. https://build.opensuse.org/package/show/devel:gcc/gcc13 -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023/06/01 21:44, Simon Lees wrote:
Not sure specifically, but it seems you are doing it a really hard way. The gcc13 package from [1] should be co installable with the system gcc.
---- gcc13 has reqs on a whole new set of libs. They'd have to be installed too. That could easily result in a non-working system. :-(
On 6/2/23 14:40, L. A. Walsh wrote:
On 2023/06/01 21:44, Simon Lees wrote:
Not sure specifically, but it seems you are doing it a really hard way. The gcc13 package from [1] should be co installable with the system gcc.
---- gcc13 has reqs on a whole new set of libs. They'd have to be installed too. That could easily result in a non-working system. :-(
They should all be co installable fine as long as it doesn't remove or update libs, my understanding is it should just ship a second version of them. I'm guessing it probably won't work properly without those libs. Atm I am pretty sure I also have gcc-11 installed on my Leap machine mostly because it was the other one in the repos. But i'm pretty sure we always setup gcc versions to be co installable looks like I have 12 + 13 installed on my tumbleweed machine. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Fri, Jun 2, 2023 at 8:11 AM L. A. Walsh <suse@tlinx.org> wrote:
On 2023/06/01 21:44, Simon Lees wrote:
Not sure specifically, but it seems you are doing it a really hard way. The gcc13 package from [1] should be co installable with the system gcc.
---- gcc13 has reqs on a whole new set of libs. They'd have to be installed too. That could easily result in a non-working system. :-(
We know neither your distribution nor where you got these packages from.
On 2023/06/01 23:29, Andrei Borzenkov wrote:
We know neither your distribution nor where you got these packages from.
I got the packages from: https://mirrors.kernel.org/opensuse/tumbleweed/repo/oss/x86_64/ which, AFAIK, should have the latest binaries. I.e. the distribution I'm getting binaries from is the current/latest TW distro.
On 02.06.2023 18:17, L A Walsh wrote:
On 2023/06/01 23:29, Andrei Borzenkov wrote:
We know neither your distribution nor where you got these packages from.
I got the packages from: https://mirrors.kernel.org/opensuse/tumbleweed/repo/oss/x86_64/
which, AFAIK, should have the latest binaries.
I.e. the distribution I'm getting binaries from is the current/latest TW distro.
But you try to install it on something entirely different and still do not tell where.
On 2023/06/02 09:38, Andrei Borzenkov wrote:
But you try to install it on something entirely different and still do not tell where.
Yes, I did, "/home/devel/root/".({usr{bin,lib64...},etc...} As for what is installed in "/" -- some old version of TW -- which is why I want to install the new version into a separate subdir. The root is too old to support direct installation of the rpm w/o needing to load many deps that would create their own problem. That is why I want what is in the root to be ignored.
participants (5)
-
Andrei Borzenkov -
L A Walsh -
L. A. Walsh
-
Larry Len Rainey -
Simon Lees