https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #21 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- I have a similar issue under Debian/unstable with GCC old of a few months, where in x86_64-pc-linux-gnu/libstdc++-v3/po, msgfmt fails with an error like /usr/bin/msgfmt: /home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib/x86_64-linux-gnu/libicuuc.so.71) A msgfmt wrapper with "printenv LD_LIBRARY_PATH" shows that LD_LIBRARY_PATH is set to /home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libsanitizer/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libvtv/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libssp/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libgomp/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libitm/.libs:/home/vlefevre/software/gcc-build/x86_64-pc-linux-gnu/libatomic/.libs:/home/vlefevre/software/gcc-build/./gcc:/home/vlefevre/software/gcc-build/./prev-gcc This bug is probably still present in master: I do not get any failure, probably because the built libstdc++.so.6 is recent enough to be similar to the one currently provided by Debian/unstable, but the wrapper still shows that LD_LIBRARY_PATH is set to the above string (or similar), so that the bug could still occur when the system libstdc++.so.6 gets something new. I suppose that LD_LIBRARY_PATH is set because it is needed in order to use built libraries. But perhaps that instead, a run path should be used together with --disable-new-dtags (so that it overrides the user's LD_LIBRARY_PATH).
