Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Mon, May 9, 2016 at 4:10 PM, Andrew Pinski wrote: > This sounds like a good use of --with-build-sysroot instead of just > --with-sysroot. > I use the following for the candian cross: > --with-sysroot=/ --with-build-sysroot=${SYSROOT} Hi Andrew! Thanks for your comment. I thought that --with-build-sysroot is only for cross-compiler builds? I have to admit I'm not very clear on the way that all the cross-compiler options are intended to be used, but I am pretty sure that it's not relevant for my case. I have a cross-compiler that *seems* perfectly functional, for which I specify: --build = host --host = host --target = target --with-sysroot = the sysroot dir --with-build-sysroot = the sysroot dir Then I'm using that compiler to build a target-native compiler installed into the sysroot directory, for which I'm specifying: --build = host --host = target --target = target --with-local-prefix = the sysroot dir Do you think things will work better for the target-native compiler if I use a sysroot option for it as well? Aside from the C++ header path lookup thing that GCC 6.1 introduced, I haven't had any problems with the target-native compiler. (I'm able to build at least tcl, expect, dejagnu, and perl with it already.) -- Brett Neumeier (bneume...@gmail.com)
Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
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 发送日期: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 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
Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
We use neither --with-sysroot nor --with-build-sysroot. The reason is that, the hard-coded path in GCC repository - that is, the /mingw/ one - does not actually exist. In order to build GCC for mingw targets, we take either solution: 0) Make a symlink (or rather, a copy, since Windows does not support symlinks) as /mingw/, as mentioned in https://sourceforge.net/p/mingw-w64/wiki2/Native%20Win64%20compiler/ 1) Replace the non-existent path with an existent one, as done in https://github.com/lhmouse/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD#L112 -- Best regards, lh_mouse 2016-05-10 - 发件人:Andrew Pinski 发送日期:2016-05-10 05:10 收件人:Brett Neumeier 抄送:lh_mouse,Jonathan Wakely,gcc 主题:Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier wrote: > On Tue, May 3, 2016 at 10:01 AM, lh_mouse 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. This sounds like a good use of --with-build-sysroot instead of just --with-sysroot. I use the following for the candian cross: --with-sysroot=/ --with-build-sysroot=${SYSROOT} Thanks, Andrew > > Cheers, > > Brett
Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier wrote: > On Tue, May 3, 2016 at 10:01 AM, lh_mouse 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. This sounds like a good use of --with-build-sysroot instead of just --with-sysroot. I use the following for the candian cross: --with-sysroot=/ --with-build-sysroot=${SYSROOT} Thanks, Andrew > > Cheers, > > Brett
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 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
Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
Should I file a bug report then? We need some Linux testers, though not many people on Linux relocate compilers. -- Best regards, lh_mouse 2016-05-03 - 发件人:Jonathan Wakely 发送日期:2016-05-03 17:00 收件人:lh_mouse 抄送:gcc 主题:Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows On 2 May 2016 at 11:41, lh_mouse wrote: > However, I am not exactly clear about whether it is these headers (cstdlib > and cmath currently, there might be more) that are the problem. No, it's only those two. > In my point of view, it is the inversion of C and C++ header paths that is > the problem. Agree. I don't know why that happens though.
Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On 2 May 2016 at 11:41, lh_mouse wrote: > However, I am not exactly clear about whether it is these headers (cstdlib > and cmath currently, there might be more) that are the problem. No, it's only those two. > In my point of view, it is the inversion of C and C++ header paths that is > the problem. Agree. I don't know why that happens though.
Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
I made some investigation yesterday and here is the result: ``` Diff'ing gcc/libstdc++-v3/include/c_global/cstdlib from gcc-5-branch and gcc-6-branch gives the following result: (git diff gcc-5-branch gcc-6-branch -- libstdc++-v3/include/c_global/cstdlib) ``` @@ -69,7 +69,11 @@ namespace std #else -#include +// Need to ensure this finds the C library's not a libstdc++ +// wrapper that might already be installed later in the include search path. +#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS +#include_next +#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS // Get rid of those macros defined in in lieu of real functions. #undef abort ``` Replacing #include_next with #include fixes the problem. However, I am not exactly clear about whether it is these headers (cstdlib and cmath currently, there might be more) that are the problem. In my point of view, it is the inversion of C and C++ header paths that is the problem. -- Best regards, lh_mouse 2016-05-02