[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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