On Thu, 13 Mar 2025, 01:39 Dennis Clarke, <dclarke@xxxxxxxxxxxxx> wrote: > 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. > It has nothing to do with the library paths. I already sent links to the relevant bugs that are probably the cause.
