1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
qt-bugs@ issue : 199610
Trolltech task ID :
bugs.kde.org number :
applied: no
author: Benjamin Reed <rangerrick@befunk.com>
I don't have the exact output anymore (I've since patched Qt's configure) but
essentially, since I have pcre.h in /opt/kde4-deps/include, it was
conflicting with Qt's (modified) pcre.h in the WebKit bits, since
-I /opt/kde4-deps/include ends up in CXXFLAGS in the generated makefiles, it
comes *before* the specific locations in INCPATH on the compile line, and you
end up with a conflict with the system-installed pcre.h.
Presumably, if your pcre.h is in /usr/include as on most Linux systems, you
wouldn't notice this issue since /usr/include's already in your include path
and people likely don't pass -I /usr/include to configure. I suspect that on
any platform with a regular, system-installed pcre.h (or clucene headers),
adding -I /usr/include would exhibit this bug, just as a custom-installed
pcre/clucene in another root would.
This patch adds support for using -isystem to allow putting an include
directory at the end of the compiler's header search path.
--- a/configure
+++ b/configure
@@ -845,6 +845,11 @@ while [ "$#" -gt 0 ]; do
VAL=`echo $1 | sed 's,-D,,'`
fi
;;
+ -isystem)
+ VAR="add_isystempath"
+ shift
+ VAL="$1"
+ ;;
-I?*|-I)
VAR="add_ipath"
if [ "$1" = "-I" ]; then
@@ -1805,6 +1810,9 @@ while [ "$#" -gt 0 ]; do
add_ipath)
I_FLAGS="$I_FLAGS -I\"${VAL}\""
;;
+ add_isystempath)
+ I_FLAGS="$I_FLAGS -isystem \"${VAL}\""
+ ;;
add_lpath)
L_FLAGS="$L_FLAGS -L\"${VAL}\""
;;
|
