1:32 p.m.
Hi
qt-creator builds have started to fail, I've reduced the failure down to
having "-isystem /usr/include" in the command line:
$ cat test.cpp
#include <algorithm>
$ g++ -isystem /usr/include -c -o test.o test.cpp
In file included from /usr/include/c++/6.0.0/bits/stl_algo.h:59:0,
from /usr/include/c++/6.0.0/algorithm:62,
from test.cpp:1:
/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such
file or directory
#include_next <stdlib.h>
Without the -isystem /usr/include, it compiles.
Bug in GCC?
Thanks
Sandro
1:38 p.m.
On Tue, Feb 02, 2016 at 01:32:17PM +0100, Sandro Mani wrote:
Hi
qt-creator builds have started to fail, I've reduced the failure down to
having "-isystem /usr/include" in the command line:
Don't use -isystem /usr/include for C++, unless you also include first all
the C++ include directories as -isystem too. Why do you need that?
-isystem /usr/include is the default, but in proper place, not prepended
before system headers.
$ cat test.cpp
#include <algorithm>
$ g++ -isystem /usr/include -c -o test.o test.cpp
In file included from /usr/include/c++/6.0.0/bits/stl_algo.h:59:0,
from /usr/include/c++/6.0.0/algorithm:62,
from test.cpp:1:
/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such file or
directory
#include_next <stdlib.h>
Without the -isystem /usr/include, it compiles.
Bug in GCC?
No.
Jakub
1:50 p.m.
On 02.02.2016 13:38, Jakub Jelinek wrote:
On Tue, Feb 02, 2016 at 01:32:17PM +0100, Sandro Mani wrote:
> Hi
>
> qt-creator builds have started to fail, I've reduced the failure down to
> having "-isystem /usr/include" in the command line:
Don't use -isystem /usr/include for C++, unless you also include first all
the C++ include directories as -isystem too. Why do you need that?
-isystem /usr/include is the default, but in proper place, not prepended
before system headers.
QMake is generating such Makefiles. Looks like the
combination of
/usr/lib64/qt5/mkspecs/common/gcc-base.conf: QMAKE_CFLAGS_ISYSTEM
= -isystem
and
/usr/lib64/qt5/mkspecs/common/qconfig.pri: QMAKE_DEFAULT_INCDIRS =
/usr/include/c++/5.3.1 /usr/include/c++/5.3.1/x86_64-redhat-linux
/usr/include/c++/5.3.1/backward
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include /usr/local/include
/usr/include
From which it seems that the actual cause of the issue is that
qt5-qtbase is not yet rebuilt against GCC6 and hence the C++ includes
are missing.
1:54 p.m.
On Tue, Feb 02, 2016 at 01:50:58PM +0100, Sandro Mani wrote:
On 02.02.2016 13:38, Jakub Jelinek wrote:
>On Tue, Feb 02, 2016 at 01:32:17PM +0100, Sandro Mani wrote:
>>Hi
>>
>>qt-creator builds have started to fail, I've reduced the failure down to
>>having "-isystem /usr/include" in the command line:
>Don't use -isystem /usr/include for C++, unless you also include first all
>the C++ include directories as -isystem too. Why do you need that?
>-isystem /usr/include is the default, but in proper place, not prepended
>before system headers.
QMake is generating such Makefiles. Looks like the combination of
/usr/lib64/qt5/mkspecs/common/gcc-base.conf: QMAKE_CFLAGS_ISYSTEM =
-isystem
and
/usr/lib64/qt5/mkspecs/common/qconfig.pri: QMAKE_DEFAULT_INCDIRS =
/usr/include/c++/5.3.1 /usr/include/c++/5.3.1/x86_64-redhat-linux
/usr/include/c++/5.3.1/backward
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include /usr/local/include
/usr/include
From which it seems that the actual cause of the issue is that qt5-qtbase is
not yet rebuilt against GCC6 and hence the C++ includes are missing.
Then a rebuild of whatever package contains that could help.
That said, why does it bother to do such a mess? Does it think the g++
driver is not able to do that itself?
Jakub
8:52 a.m.
On 2 February 2016 at 07:50, Sandro Mani wrote:
On 02.02.2016 13:38, Jakub Jelinek wrote:
> On Tue, Feb 02, 2016 at 01:32:17PM +0100, Sandro Mani wrote:
> Don't use -isystem /usr/include for C++, unless you also include first all
> the C++ include directories as -isystem too. Why do you need that?
> -isystem /usr/include is the default, but in proper place, not prepended
> before system headers.
QMake is generating such Makefiles. Looks like the combination of
/usr/lib64/qt5/mkspecs/common/gcc-base.conf: QMAKE_CFLAGS_ISYSTEM =
-isystem
and
/usr/lib64/qt5/mkspecs/common/qconfig.pri: QMAKE_DEFAULT_INCDIRS =
/usr/include/c++/5.3.1 /usr/include/c++/5.3.1/x86_64-redhat-linux
/usr/include/c++/5.3.1/backward
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include /usr/local/include
/usr/include
From which it seems that the actual cause of the issue is that qt5-qtbase is
not yet rebuilt against GCC6 and hence the C++ includes are missing.
The current (as of this email) qt5-qtbase is built with GCC6, but the
issue persists.
The builds seem fine with the above QMAKE_DEFAULT_INCDIRS line removed
manually. Should this issue be fixed in the qt5-qtbase package?
Thanks,
Orcan
12:42 a.m.
Orcan Ogetbil wrote:
The current (as of this email) qt5-qtbase is built with GCC6, but
the
issue persists.
The builds seem fine with the above QMAKE_DEFAULT_INCDIRS line removed
manually. Should this issue be fixed in the qt5-qtbase package?
what package is affected here?
I have a suspicion that QMAKE_DEFAULT_INCDIRS is being misused in this
context.
-- rex
7:46 a.m.
On 14 February 2016 at 18:42, Rex Dieter wrote:
Orcan Ogetbil wrote:
> The current (as of this email) qt5-qtbase is built with GCC6, but the
> issue persists.
> The builds seem fine with the above QMAKE_DEFAULT_INCDIRS line removed
> manually. Should this issue be fixed in the qt5-qtbase package?
what package is affected here?
I have a suspicion that QMAKE_DEFAULT_INCDIRS is being misused in this
context.
The new version of qjackctl, which now depends on qt5. We cannot do
the update without fixing this. As far as I can tell, the qjackctl
does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
come through qmake.
Other than this the new qsynth also has the same issue when built with
autotools. Fortunately, qsynth provides an alternative cmake build
system which doesn't call qmake. We were able to build qsynth with
that one.
I don't know any other examples but I suspect any package using
qmake-qt5 could have this problem.
Orcan
7:50 a.m.
On 15 February 2016 at 01:46, Orcan Ogetbil wrote:
The new version of qjackctl, which now depends on qt5. We cannot do
the update without fixing this. As far as I can tell, the qjackctl
does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
come through qmake.
Here is a scratch SRPM which can be used for testing:
https://oget.fedorapeople.org/qjackctl/qjackctl-0.4.1-1.fc23.src.rpm
Orcan
4:24 a.m.
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 noticed the difference: In cstdlib, the gcc5 line 75
#include <stdlib.h>
became in gcc6:
#include_next <stdlib.h>
Thanks,
Orcan
11:42 a.m.
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.
6:51 p.m.
Orcan Ogetbil wrote:
On 14 February 2016 at 18:42, Rex Dieter wrote:
> what package is affected here?
>
> I have a suspicion that QMAKE_DEFAULT_INCDIRS is being misused in this
> context.
The new version of qjackctl, which now depends on qt5. We cannot do
the update without fixing this. As far as I can tell, the qjackctl
does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
come through qmake.
...
I don't know any other examples but I suspect any package using
qmake-qt5 could have this problem.
I suspect your suspicion is wrong, but I'll take a look to be sure. :)
-- Rex
7:08 p.m.
Orcan Ogetbil wrote:
On 15 February 2016 at 01:46, Orcan Ogetbil wrote:
>
> The new version of qjackctl, which now depends on qt5. We cannot do
> the update without fixing this. As far as I can tell, the qjackctl
> does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
> come through qmake.
>
Here is a scratch SRPM which can be used for testing:
https://oget.fedorapeople.org/qjackctl/qjackctl-0.4.1-1.fc23.src.rpm
OK, so, here's how it happens, src/src.pri.in contains:
INCLUDEPATH += @ac_incpath@
and that gets populated by configure, which happens to include...
/usr/include
So, 2 options (not mutually exclusive):
* fix configure to not add /usr/include to ac_incpath
* fix src/src.pri.in to comment-out (or remove) the line starting with
INCLUDEPATH += (I don't think it's needed)
-- Rex
7:16 p.m.
Rex Dieter wrote:
Orcan Ogetbil wrote:
> On 14 February 2016 at 18:42, Rex Dieter wrote:
>> what package is affected here?
>>
>> I have a suspicion that QMAKE_DEFAULT_INCDIRS is being misused in this
>> context.
>
> The new version of qjackctl, which now depends on qt5. We cannot do
> the update without fixing this. As far as I can tell, the qjackctl
> does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
> come through qmake.
...
> I don't know any other examples but I suspect any package using
> qmake-qt5 could have this problem.
I suspect your suspicion is wrong, but I'll take a look to be sure. :)
I'll think on this more, we may end up adjusting QMAKE_DEFAULT_INCDIRS
too... needs more investigation.
-- Rex
8:34 a.m.
On 16 February 2016 at 13:08, Rex Dieter wrote:
So, 2 options (not mutually exclusive):
* fix configure to not add /usr/include to ac_incpath
* fix src/src.pri.in to comment-out (or remove) the line starting with
INCLUDEPATH += (I don't think it's needed)
Yes, I could use those to workaround/fix the include path issue. But
there is more to it. I also have to do
echo "QMAKE_STRIP = echo" >> src/src.pro
Otherwise the final binary gets stripped by default.
I think I am standing behind my suspicion that qmake is behaving
differently than before.
Take a look at /usr/lib64/qt5/mkspecs/common/linux.conf for the
definition of QMAKE_STRIP. It is empty in qt-5.5, but not in qt-5.6.
Orcan
7:07 p.m.
Orcan Ogetbil wrote:
On 16 February 2016 at 13:08, Rex Dieter wrote:
> So, 2 options (not mutually exclusive):
>
> * fix configure to not add /usr/include to ac_incpath
> * fix src/src.pri.in to comment-out (or remove) the line starting with
> INCLUDEPATH += (I don't think it's needed)
>
Yes, I could use those to workaround/fix the include path issue. But
there is more to it. I also have to do
echo "QMAKE_STRIP = echo" >> src/src.pro
Otherwise the final binary gets stripped by default.
The qmake-qt5.sh wrapper used by this package should already include:
QMAKE_STRIP=
-- Rex
7:38 p.m.
On 15/02/16 07:46, Orcan Ogetbil wrote:
The new version of qjackctl, which now depends on qt5. We cannot do
the update without fixing this. As far as I can tell, the qjackctl
does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
come through qmake.
Other than this the new qsynth also has the same issue when built with
autotools. Fortunately, qsynth provides an alternative cmake build
system which doesn't call qmake. We were able to build qsynth with
that one.
I don't know any other examples but I suspect any package using
qmake-qt5 could have this problem.
This also affects qtractor
B
2:43 p.m.
Brendan Jones wrote:
On 15/02/16 07:46, Orcan Ogetbil wrote:
> The new version of qjackctl, which now depends on qt5. We cannot do
> the update without fixing this. As far as I can tell, the qjackctl
> does not use the QMAKE_DEFAULT_INCDIRS directly. The offending flags
> come through qmake.
>
> Other than this the new qsynth also has the same issue when built with
> autotools. Fortunately, qsynth provides an alternative cmake build
> system which doesn't call qmake. We were able to build qsynth with
> that one.
>
> I don't know any other examples but I suspect any package using
> qmake-qt5 could have this problem.
>
This also affects qtractor
Thanks, I applied a similar fix there too.
-- Rex
2977
days inactive
3004
days old
16 comments
6 participants
participants (6)
-
Brendan Jones -
Jakub Jelinek -
Jonathan Wakely -
Orcan Ogetbil -
Rex Dieter -
Sandro Mani