This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936

            Bug ID: 70936
           Summary: Hard-coded C++ header paths and relocation problem on
                    Windows
           Product: gcc
           Version: 6.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]