On 3/12/25 17:53, Jonathan Wakely wrote:
On Wed, 12 Mar 2025 at 20:56, Dennis Clarke <dclarke@xxxxxxxxxxxxx> wrote:
On 3/12/25 16:19, Jonathan Wakely wrote:
On Wed, 12 Mar 2025 at 20:11, Dennis Clarke <dclarke@xxxxxxxxxxxxx> wrote:
On 3/12/25 15:59, Jonathan Wakely wrote:
On Wed, 12 Mar 2025 at 19:58, Dennis Clarke <dclarke@xxxxxxxxxxxxx> wrote:
t$
t$ ./tz_test
./tz_test: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.32' not found (required by ./tz_test)
./tz_test: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.31' not found (required by ./tz_test)
t$
Now this is getting strange.
No it isn't:
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
You can just use -static-libstdc++ for this test.
This sort of thing is none too helpful :
t$
t$ LD_LIBRARY_PATH=/opt/bw/lib ./tz_test
ersatz
t$
t$ LD_LIBRARY_PATH=/opt/bw/gcc14/lib64 ./tz_test
ersatz
t$
So I need to remove the default system GCC packages
No, don't mess with the system GCC unless you know what you're doing
(and the fact we're having this discussion about it says you don't
really).
Well using LD_LIBRARY_PATH is just horrific. Unless one is testing
something very temporary. Perfect for that sort of thing. Otherwise
horrific if a user needs that _all_ the time.
and then drop the
new /opt/bw/gcc14/lib64/libstdc++.so.6.0.33 thing into a well known
location for GCC to work right ? Really ?
No, there are better solutions, as described at the link above, and
the chapter of the libstdc++ manual that it links to.
I looked at what ldconfig has to say and note that the default Debian
type stuff claims a few places are on the list to look for libs :
# cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
t#
So I guess I will drop the new libstdc++.so.6.0.33 with its symlinks in
to /usr/local/lib/x86_64-linux-gnu and then rebuild the ldconfig cache.
Yup .. that works :
t$ ldd tz_test
linux-vdso.so.1 (0x00007ffcc1b45000)
libstdc++.so.6 =>
/usr/local/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f063ba00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f063bd19000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f063b9e0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f063b7ff000)
/lib64/ld-linux-x86-64.so.2 (0x00007f063be07000)
t$
Now I am curious what happens when I re-bootstrap GCC and redo the
testsuite with those timezone FAILs? Maybe they vanish? Maybe not.
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
