Hello, For a reminder, this is the issue that I was posting at:
http://lists.linuxfromscratch.org/pipermail/blfs-dev/2018-February/033969.html After basic investigation, I saw the issue being reported there on gcc bugzilla marked as WONTFIX: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 The issue is with the -isystem /usr/include directive with g++ when it is used to import a C header into the C++ program (in my case, it happen during compilation of g++ itself). The most comprehensive fix would be to replace every occurance of: #include_next <math.h> (or any other C header ending with *.h) with #include <math> using namespace std (anonymous namespace? I'm not familiar with the concept of namespace). But I have to admit this fix would amount to a massive undertaking if only 25% of the softwares in LFS/BLFS would be fixed. I'm also thinking about my last few attempts at building LFS with a supplementary gcc installation by BLFS method (i.e. C,C++, Fortran, go, objc and objc++) by hand under which I let LFS gcc chapter 5 second installation, chapter 6 installation and BLFS installation enabling bootstraping (I use --enable-bootstrap) because the installation might use precompiled headers, for which the fix is reported here: http://answers.opencv.org/question/183401/gcc7-stdlibh-no-such-file-or-directory-include_next-stdlib h/ I'll try another build tonight switching all precompiled headers off but still bootstraping the build to see if that fix it. Second step would be to drop off the --enable-bootstrap (i.e. -- disable-bootstrap in all case or at least, during all the LFS build steps). Alain -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
