https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936
Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |i686-w64-mingw32 --- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to lh_mouse from comment #0) > The following message is copied from > https://gcc.gnu.org/ml/gcc/2016-05/msg00003.html > ``` > > This is a cross-post from gcc-help as there haven't been any replies on > gcc-help since two days ago. Hope someone could help. > ``` > > I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows > today. > Now I have a relocation problem: > > Assuming mingw-w64 headers are located in the follow directory,which is, the > native_system_header_dir: > > C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include > I have built GCC and it has that hard-coded path. > When I compile something using g++ -v, the headers are searched in the > following paths: > ``` > ignoring nonexistent directory "/mingw32/include" > ignoring duplicate directory > "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include" > #include "..." search starts here: > #include <...> search starts here: > C:/MinGW/MSYS2/mingw32/include/c++/6.1.1 > C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/i686-w64-mingw32 > C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/backward > C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include > C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../include > C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include-fixed > C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64- > mingw32/include > End of search list. > ``` > The C++ headers are searched before any mingw-w64 headers, which is just > fine. > > However, if I move gcc to another directory, let's say, > C:/this_is_a_new_directory/mingw32/, > then re-compile the same program with g++ -v, the headers are searched in > the following paths: > ``` > ignoring duplicate directory > "C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6. > 1.1/include" > ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include" > ignoring nonexistent directory "/mingw32/include" > ignoring duplicate directory > "C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6. > 1.1/include-fixed" > ignoring duplicate directory > "C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6. > 1.1/../../../../i686-w64-mingw32/include" > ignoring nonexistent directory > "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include" > #include "..." search starts here: > #include <...> search starts here: > C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/ > include > C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../ > ../../../include > C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/ > include-fixed > C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../ > ../../../i686-w64-mingw32/include > C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1 > C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/i686-w64- > mingw32 > C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/backward > End of search list. > ``` > This time the C++ headers are searched after mingw-w64 headers, which causes > the following error: > ``` > In file included from > C:/MinGW/mingw32/include/c++/6.1.1/ext/string_conversions.h:41:0, > from > C:/MinGW/mingw32/include/c++/6.1.1/bits/basic_string.h:5402, > from C:/MinGW/mingw32/include/c++/6.1.1/string:52, > from > C:/MinGW/mingw32/include/c++/6.1.1/bits/locale_classes.h:40, > from C:/MinGW/mingw32/include/c++/6.1.1/bits/ios_base.h:41, > from C:/MinGW/mingw32/include/c++/6.1.1/ios:42, > from C:/MinGW/mingw32/include/c++/6.1.1/ostream:38, > from C:/MinGW/mingw32/include/c++/6.1.1/iostream:39, > from test.cpp:1: > C:/MinGW/mingw32/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No > such file or directory > #include_next <stdlib.h> > ^ > compilation terminated. > ``` > > Do you know how to solve this problem (modifications to gcc source code are > expected)? > Thanks in advance. > > > > -------------- > Best regards, > lh_mouse > 2016-05-02 > > 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 <stdlib.h> > +// Need to ensure this finds the C library's <stdlib.h> not a libstdc++ > +// wrapper that might already be installed later in the include search path. > +#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS > +#include_next <stdlib.h> > +#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS > > // Get rid of those macros defined in <stdlib.h> 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