GCC6: failure with -isystem /usr/include
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 $ 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 Without the -isystem /usr/include, it compiles. Bug in GCC? Thanks Sandro -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 > > $ 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 > > > Without the -isystem /usr/include, it compiles. > > Bug in GCC? No. Jakub -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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
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
became in gcc6:
#include_next
Thanks,
Orcan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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
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
became in gcc6:
#include_next
Yes, this is necessary because the C++ standard library now provides
its own , so for 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
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GCC6: failure with -isystem /usr/include
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 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
