Hard-coded C++ paths and reloation problem on Windows

[lh_mouse]

Hi all.

I built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows a few days ago.
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.
```

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.

Discussion is welcome. Thanks in advance.



 				
--------------
Best regards,
lh_mouse
2016-04-28