Quantcast
Viewing all articles
Browse latest Browse all 5180

C/C++ • Re: how to resolve 'glibc_2.34 not found'

Re gcc12: this should be enough to build 12.3.0. Snipped from a "config.log"..

Code:

  $ ../gcc-12.3.0/configure --prefix=/usr/local/GCC/12.3.0 --enable-languages=c,c++ --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu## --------- #### Platform. #### --------- ##hostname = pi23uname -m = aarch64uname -r = 6.1.21-v8+uname -s = Linuxuname -v = #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023
You'll need..

Code:

gmp-6.2.1mpfr-4.1.0mpc-1.2.1isl-0.24
..which can be obtained via "./contrib/download_prerequisites" - unpack the gcc 12.3.0 sources.

If you..

Code:

$ sudo mkdir /usr/local/GCC$ sudo chown -v `id -un`:`id -gn` /usr/local/GCC
..then you will be able to unpack/configure/build/install without being root.

Note I'm typing this off the top of my head, fishing details out of a script..

Code:

#Get the sources..$ cd$ mkdir -p ~/usr/src/gcc$ cd usr/src/gcc$ wget https://mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-12.3.0/gcc-12.3.0.tar.xz$ tar xvJf gcc-12.3.0.tar.xz$ pushd gcc-12.3.0$ ./contrib/download_prerequisites$ popd#Now to the build..$ mkdir -p obj$ pushd obj$  ../gcc-12.3.0/configure --prefix=/usr/local/GCC/12.3.0 --enable-languages=c,c++ --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu#hint (*)$ make -j $(nproc)$ make install#Check it's there..$ /usr/local/GCC/12.13.0/bin/gcc -v
Build this on your oldest dev system, aka Buster. It will take an age so some detachable terminal (tmux or screen) would be handy.

My script, for example, creates a front-end to drive this new compiler..

Code:

foo@pi23:~/usr/src/gcc $ cat /usr/local/GCC/12.3.0/bin/sd-gcc#!/bin/bashPATH=/usr/local/GCC/12.3.0/bin:$PATH \LD_LIBRARY_PATH=/usr/local/GCC/12.3.0/lib64:/usr/local/GCC/12.3.0/lib:/usr/local/GCC/12.3.0/lib32 \MANPATH=/usr/local/GCC/12.3.0/share/man \INFOPATH=/usr/local/GCC/12.3.0/share/info \"$@"
Create that manually in your case then you can issue..

Code:

foo@pi23:~/usr/src/gcc $ /usr/local/GCC/12.3.0/bin/sd-gcc g++ -vUsing built-in specs.COLLECT_GCC=g++COLLECT_LTO_WRAPPER=/usr/local/GCC/12.3.0/libexec/gcc/aarch64-linux-gnu/12.3.0/lto-wrapperTarget: aarch64-linux-gnuConfigured with: ../gcc-12.3.0/configure --prefix=/usr/local/GCC/12.3.0 --enable-languages=c,c++ --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnuThread model: posixSupported LTO compression algorithms: zlibgcc version 12.3.0 (GCC)
Hint: create a symlink to that in ~/bin/ or /usr/local/bin/ as applicable. Now you only need to say..

Code:

$ sd-gcc g++ -v 2>&1 | grep ^gccgcc version 12.3.0 (GCC)
Now you have a usable gcc 12.3.0 "sideloaded" (to use an android term). You can use 'sd-gcc' as a compiler front-end in a similar manner to how 'distcc' works. However, if 'cmake' (as opposed to 'configure') is involved it's usually enough to simply point CC and CXX at /usr/local/GCC/12.3.0/bin/gcc & /usr/local/GCC/12.3.0/bin/g++ respectively - often just setting CC alone is enough. However, because 'cmake' is effectively a programming language and is thus buggy at a user level it's best to invoke it with 'sd-gcc' to give it a better chance..

Code:

$ sd-gcc cmake #blah
..in case there's a bug in the project code (ie: it wanders off deep inside and a subproject invokes a 'configure') - it'll find "sd-gcc" in the $PATH before the system compiler. There's nothing harder than trying to debug a project which has (ahem "successfully" built using a mixture of compilers).

Run your gcc 12.3.0 app with..

Code:

$ sd-gcc path/to/your/app
..because that will give preference to /usr/local/GCC/12.3.0/ stuff (rather than system stuff).

As advised by @tttapa, don't try to patch the glbc version. If you search through this forum you'll find a script which can build gcc for you. All you need to know with that is the "--prefix" option to gcc when configuring it is where it will get installed. My method is more generic and doesn't require being root, except for that one time to create the installation folder.

Now. If you're really lucky, you might be able to copy that Buster /usr/local/GCC/12.3.0/ to a Bookworm system and find it works. It doesn't really matter because if it doesn't (and I'd recommend this anyway) simply repeat the above process on your dev Bookworm system.

I've decided to waffle on about this because you mention issues with gcc 10. I've found gcc 12.3.0 to be problem-free on Bullseye and Bookworm. Should you decide to build your own gcc, hold off on temptation to go with gcc 13.x (reasons). There probably isn't anything wrong with gcc 10 btw. Consider..

Code:

foo@pi23:/wrk/T $ cat /etc/os-release | grep ENAMEVERSION_CODENAME=bullseyefoo@pi23:/wrk/T $ cat c.cc#include <iostream>intmain(){ std::cout << "Hello c++ World\n"; return 0;}$ g++ -o c c.cc$ sd-gcc g++ -o cc c.cc
Here's a subtle breakage. It's bad because it "works"..

Code:

$ ./cHello c++ World$ ./ccHello c++ World
Why is it broken? Look..

Code:

foo@pi23:/wrk/T $ ldd clinux-vdso.so.1 (0x0000007fa5e8a000)libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007fa5c59000)libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa5ae5000)libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fa5a3a000)libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fa5a16000)/lib/ld-linux-aarch64.so.1 (0x0000007fa5e5a000)
^^compiled with system compiler.

Code:

foo@pi23:/wrk/T $ ldd cclinux-vdso.so.1 (0x0000007fb7433000)libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007fb7214000)libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007fb7169000)libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007fb7145000)libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fb6fd1000)/lib/ld-linux-aarch64.so.1 (0x0000007fb7403000)
^^compiled with sd-gcc (/usr/local/GCC/12.3.0/)

The 'ldd' tool is easily misused. Consider this..

Code:

foo@pi23:/wrk/T $ sd-gcc ldd cclinux-vdso.so.1 (0x0000007f87222000)libstdc++.so.6 => /usr/local/GCC/12.3.0/lib64/libstdc++.so.6 (0x0000007f86fcf000)libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f86f0d000)libgcc_s.so.1 => /usr/local/GCC/12.3.0/lib64/libgcc_s.so.1 (0x0000007f86ee8000)libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f86d74000)/lib/ld-linux-aarch64.so.1 (0x0000007f871f2000)
^^as it should be. Different "libstdc++.so.6" and "libgcc_s.so.1". The correct invocation is..

Code:

foo@pi23:/wrk/T $ sd-gcc ./ccHello c++ World
..otherwise we're running "./cc" against those two system libs instead of the ones "./cc" was compiled against. The fact your code broke is a good thing. Imagine the mess which might happen if this went unnoticed: one day a non-trivial app might demonstrate undefined behaviour (incidentally this is one reason many folk don't like the idea of cross-compiling).

If you can get to grips with $PATH and $LD_LIBRARY_PATH it may be you don't need to build (say) gcc 12.3.0 at all but the best way to discover that is to build the Buster version and see if it works on Bookworm. If it does, you didn't need to have built it (copying the missing libs would have sufficed). Irony Image may be NSFW.
Clik here to view.
;-)

Statistics: Posted by swampdog — Thu May 02, 2024 2:58 pm



Viewing all articles
Browse latest Browse all 5180

Trending Articles