https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #26 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to Jonathan Wakely from comment #23) > (In reply to Vincent Lefèvre from comment #21) > > I suppose that LD_LIBRARY_PATH is set because it is needed in order to use > > built libraries. > > It is not needed except when running the testsuite, and should not be set. Indeed, for most projects. IIRC, for some project (was it Subversion?), using built libraries was needed also during a part of the build, but that said, since this is rather specific, this is probably not a reason to change LD_LIBRARY_PATH globally, in case this is what libtool does. (In reply to Sam James from comment #24) > (In reply to Vincent Lefèvre from comment #21) > > 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) > > This issue is, I think, slightly different: https://bugs.gentoo.org/843119. I think that the cause is the same (and the fix should be the same): LD_LIBRARY_PATH is changed somewhere to point to some build directories. As mentioned by https://bugs.gentoo.org/843119#c10 this shouldn't be done there. > It might end up being related but I've only ever seen *that* issue in the > context of installing libstdc++ when doing the gcc build when NLS is enabled > and using a newer GCC to do the build of an older version. While disabling NLS (Gentoo's fix) would be OK for most testing of older GCC, I doubt that this is the right solution.
