https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #8 from Romain Geissler <romain.geissler at amadeus dot com> --- Your patch is working. I may add some context to better understand this strange scenario. In my case, the config log says: configure:80434: checking for utimensat configure:80484: x86_64-1a-linux-gnu-g++ -o conftest -O2 -mmmx -msse -msse2 -msse3 -fno-exceptions -O2 -mmmx -msse -msse2 -msse3 conftest.cpp >&5 /home/jenkins/workspace/OTF_Toolchain_release_20.0-GWCRYYLPVAZ3GI64ZF43J2FVALYHUCNKGFBXVRTH6NJF73DCK7SQ/output/build/temporary-system/install/bin/../lib/gcc/x86_64-1a-linux-gnu/9.0.0/../../../../x86_64-1a-linux-gnu/bin/ld: cannot find -lstdc++ for all find of header check, so in the end they all end up being as not found. I don't just build gcc or libstdc++ in my build, actually it's a full toolchain bootstrap following what is done in Linux From Scratch. I build in that order: - binutils, with a linker configured to look for system libraries in a non-standard folder, empty for now - gcc, without libstdc++ - glibc, using the above binutils/gcc, which fills in the non standard lib folder with only a libc. - libstdc++, using the above binutils/gcc/glibc. At the moment we build this first libstdc++, there is no existing libstdc++ yet, thus the above configure failures. Note that this is just the beginning of the bootstrap. After this other gcc/libstdc++ are being built, and this time the configure script works unpatched. So with these explanations, do you think the patch you proposed should land in trunk (it worked for me in that specific bootstrap configuration).
