This is the mail archive of the
mailing list for the GCC project.
Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
- From: "lh mouse"<lh_mouse at 126 dot com>
- To: "Brett Neumeier"<bneumeier at gmail dot com>
- Cc: "Jonathan Wakely"<jwakely dot gcc at gmail dot com>, "gcc"<gcc at gcc dot gnu dot org>
- Date: Tue, 10 May 2016 11:51:34 +0800
- Subject: Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
- Authentication-results: sourceware.org; auth=none
- References: <4bee92a3 dot 11b9f7 dot 154710b7ff9 dot Coremail dot lh_mouse at 126 dot com> <27b92139 dot 11ba0f dot 154710f77eb dot Coremail dot lh_mouse at 126 dot com> <CAH6eHdTkL_L6POiuZzDY61=ESM4ZMbepRXxZVoN5-ZnkcFkwmQ at mail dot gmail dot com> <57e3f960 dot 200a dot 154772301e2 dot Coremail dot lh_mouse at 126 dot com><CAGSetNuPNq0vPvBVVhKZ7iCJiMZ7Dwy=uxSzPKejyhAOz+4M5g at mail dot gmail dot com>
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.
åääïBrett Neumeier <email@example.com>
äéï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 <firstname.lastname@example.org> 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
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.