I have a vision. It is gcc/gcc/incpath.c that the problem is in. I had been looking through that file for a few days but eventually gave up.
It is worth mentioning that adding an '-iprefix /this/need/not/exist' vanishes the problem. This might have something to do with the following line in incpath.c (it should be line #132 on gcc-6-branch at the moment): ``` if (iprefix && (len = cpp_GCC_INCLUDE_DIR_len) != 0) ``` Still I have no idea about how relocated paths are pulled in. I am looking forward to a patch for the relocation problem. ------------------ Best regards, lh_mouse 2016-05-10 ------------------------------------------------------------- 发件人：Brett Neumeier <bneume...@gmail.com> 发送日期：2016-05-10 04:31 收件人：lh_mouse 抄送：Jonathan Wakely,gcc 主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows On Tue, May 3, 2016 at 10:01 AM, lh_mouse <lh_mo...@126.com> wrote: > Should I file a bug report then? > We need some Linux testers, though not many people on Linux relocate > compilers. For what it's worth -- I encountered the same problem on a GNU/Linux system. In my specific situation, I'm cross-compiling GCC using an AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in a sysroot directory. When I try to use that GCC on a target device where (of course) the sysroot directory becomes "/", the hard-coded "/path/to/sysroot" from the host system is still used to find the C++ headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory" error message you got. Changing #include_next to #include in cstdlib and cmath fixed my problem -- so, thank you very much for this discussion! It helped at least one other person. Please let me know if there's any other testing I can do to help. Cheers, Brett
