This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
- From: "lh_mouse"<lh_mouse at 126 dot com>
- To: "gcc"<gcc at gcc dot gnu dot org>
- Date: Mon, 2 May 2016 18:41:57 +0800
- Subject: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
- Authentication-results: sourceware.org; auth=none
- References: <4bee92a3 dot 11b9f7 dot 154710b7ff9 dot Coremail dot lh_mouse at 126 dot com>
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