On 15/02/16 22:24 -0500, Orcan Ogetbil wrote:
On 2 February 2016 at 07:54, Jakub Jelinek wrote:
That said, why does it bother to do such a mess? Does it think the g++
driver is not able to do that itself?
I am not sure why qmake-qt5 doesn't want to trust gcc for the system
include dirs, but well.. it doesn't.
I reduced the problem down to this. Consider the following program:
#include <algorithm>
int main(){}
This compiles fine with both gcc5 and 6 with
g++ -c inctest.cpp -o inctest.o
On the other hand, it compiles fine with gcc5, but fails with gcc6 if
the compiler is invoked liked this:
g++ -c -isystem /usr/include inctest.cpp -o inctest.o
The failure message is
/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such
file or directory
I am not sure what is the expected behavior. Maybe people familiar
with gcc can shed some light.
I don't have any better solution than "don't do that". It is
unnecessary to tell GCC that /usr/include is a system directory, of
course it already knows that. Since it was never useful, and now
causes a problem, I think "don't do that" is the best response.
I noticed the difference: In cstdlib, the gcc5 line 75
#include <stdlib.h>
became in gcc6:
#include_next <stdlib.h>
Yes, this is necessary because the C++ standard library now provides
its own <stdlib.h>, so for <cstdlib> to include the underlying header
from the C library, /usr/include/stdlib.h, it must use #include_next.
#include_next is sensitive to the order of directories in the
preprocessor's search path, so if you change that order with -include
then the compiler can't find the right header.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
