New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qt5 / qtcreator: error stdlib.h: no such file or directory #5254

Closed
pullmoll opened this Issue Nov 29, 2016 · 11 comments

Comments

Projects
None yet
4 participants
@pullmoll
Contributor

pullmoll commented Nov 29, 2016

In my Qt5 projects I now see this error when they for example contain #include <QImage>.
The sequence of includes then is:

In file included from /usr/include/c++/6.2/bits/stl_algo.h:59:0,
                 from /usr/include/c++/6.2/algorithm:62,
                 from /usr/include/qt5/QtCore/qglobal.h:88,
                 from /usr/include/qt5/QtGui/qrgb.h:37,
                 from /usr/include/qt5/QtGui/qcolor.h:37,
                 from /usr/include/qt5/QtGui/qimage.h:37,
                 from /usr/include/qt5/QtGui/QImage:1,
                 from ../../qi/blit/blit.h:4,
                 from ../../qi/blit/blit.cpp:1:
/usr/include/c++/6.2/cstdlib:75:25: fatal error: stdlib.h: No such file or directory

We have seen this error in other places and then fixed it by surrounding the #include <stdlib.h> with

#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include <stdlib.h>
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

In this case, however, it is not the application or qt5 headers where the error happens, but internally in c++ as it seems.

The file /usr/include/c++/6.2/cstdlib has this #define and #undef around the #include <stdlib.h> and yet it fails.

I seem to remember that some Qt5 package in the repo could be fixed by setting QMAKE_CFLAGS_ISYSTEM= i.e. setting it to an empty string. It can't be right to have to do this for every project, so perhaps it should become the default in qt5.

And indeed, adding a line QMAKE_CFLAGS_ISYSTEM= to my main config.pri file for unix solves the problem.

Any suggestions or links to how other distros handle(d) this are welcome.
The question is, whether qt5 itself should set QMAKE_CFLAGS_ISYSTEM= in its profiles.

@ebfe

This comment has been minimized.

Show comment
Hide comment
@ebfe

This comment has been minimized.

Show comment
Hide comment
@pullmoll

This comment has been minimized.

Show comment
Hide comment
@pullmoll

pullmoll Nov 29, 2016

Contributor

Another reference: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5SWCUUMWQ4EMS7CU2CBOZHV3WZYOOTT/

From reading this it seems that just removing /usr/include from the QMAKE_DEFAULT_INCDIRS in /usr/lib/qt5/mkspecs/qconfig.pri might help. I'm going to play around with this and see, if I can find a fix that can be put in qt5 itself.

Edit: Oh, there is gcc4 stuff listed in that file:

    QMAKE_DEFAULT_LIBDIRS = /usr/lib /lib /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.4
    QMAKE_DEFAULT_INCDIRS = /usr/include/c++/4.9.4 /usr/include/c++/4.9.4/x86_64-unknown-linux-gnu /usr/include/
c++/4.9.4/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include /usr/local/include /usr/lib/gcc/x86_64-un
known-linux-gnu/4.9.4/include-fixed /usr/include

So qt5 needs a rebuild anyway (first).

Contributor

pullmoll commented Nov 29, 2016

Another reference: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5SWCUUMWQ4EMS7CU2CBOZHV3WZYOOTT/

From reading this it seems that just removing /usr/include from the QMAKE_DEFAULT_INCDIRS in /usr/lib/qt5/mkspecs/qconfig.pri might help. I'm going to play around with this and see, if I can find a fix that can be put in qt5 itself.

Edit: Oh, there is gcc4 stuff listed in that file:

    QMAKE_DEFAULT_LIBDIRS = /usr/lib /lib /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.4
    QMAKE_DEFAULT_INCDIRS = /usr/include/c++/4.9.4 /usr/include/c++/4.9.4/x86_64-unknown-linux-gnu /usr/include/
c++/4.9.4/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include /usr/local/include /usr/lib/gcc/x86_64-un
known-linux-gnu/4.9.4/include-fixed /usr/include

So qt5 needs a rebuild anyway (first).

@pullmoll

This comment has been minimized.

Show comment
Hide comment
@pullmoll

pullmoll Nov 30, 2016

Contributor

The error message persists even with the now correct gcc6.2.1 include paths.
Removing the last path /usr/include from the file /usr/lib/qt5/mkspecs/qconfig.pri line QMAKE_DEFAULT_INCDIRS = ... solves the issue.

I wonder if I should do yet another revbump for qt5-5.6.2 or try to update to qt5-5.7.0 and fix it there, if it's still an issue.

Contributor

pullmoll commented Nov 30, 2016

The error message persists even with the now correct gcc6.2.1 include paths.
Removing the last path /usr/include from the file /usr/lib/qt5/mkspecs/qconfig.pri line QMAKE_DEFAULT_INCDIRS = ... solves the issue.

I wonder if I should do yet another revbump for qt5-5.6.2 or try to update to qt5-5.7.0 and fix it there, if it's still an issue.

@pullmoll

This comment has been minimized.

Show comment
Hide comment
@pullmoll
Contributor

pullmoll commented Dec 2, 2016

@pullmoll pullmoll closed this Dec 2, 2016

@pullmoll pullmoll reopened this Dec 22, 2016

@pullmoll

This comment has been minimized.

Show comment
Hide comment
@pullmoll

pullmoll Dec 22, 2016

Contributor

Sadly the issue is back with qt5-5.7.1
The sed does not work, because /usr/lib/qt5/mkspecs/qconfig.pri no longer contains the QMAKE_DEFAULT_INCDIRS variable.

Need to find the new place where it's set or where else the -isystem /usr/include causing this bug comes from.

Edit: It does not help to remove /usr/include from /usr/lib/qt5/mkspecs/features/toolchain.prf

Edit2: It again helps to add QMAKE_CFLAGS_ISYSTEM= in the configuration of a project to be built with qt5-5.7.1 here. Perhaps we can just globally remove -isystem from the QMAKE_CFLAGS_ISYSTEM = -isystem line in /usr/lib/qt5/mkspecs/common/gcc-base.conf. No idea what other consequences this may have, though.

Contributor

pullmoll commented Dec 22, 2016

Sadly the issue is back with qt5-5.7.1
The sed does not work, because /usr/lib/qt5/mkspecs/qconfig.pri no longer contains the QMAKE_DEFAULT_INCDIRS variable.

Need to find the new place where it's set or where else the -isystem /usr/include causing this bug comes from.

Edit: It does not help to remove /usr/include from /usr/lib/qt5/mkspecs/features/toolchain.prf

Edit2: It again helps to add QMAKE_CFLAGS_ISYSTEM= in the configuration of a project to be built with qt5-5.7.1 here. Perhaps we can just globally remove -isystem from the QMAKE_CFLAGS_ISYSTEM = -isystem line in /usr/lib/qt5/mkspecs/common/gcc-base.conf. No idea what other consequences this may have, though.

@ebfe

This comment has been minimized.

Show comment
Hide comment
@ebfe

ebfe Dec 22, 2016

Member

FWIW, even before the update (and after the fix) several cross builds sti failed with the sllame error. For example:

https://build.voidlinux.eu/builders/aarch64-musl_builder/builds/3036/steps/shell_3/logs/stdio
https://build.voidlinux.eu/builders/armv6l_builder/builds/29973/steps/shell_3/logs/stdio
https://build.voidlinux.eu/builders/aarch64-musl_builder/builds/3032/steps/shell_3/logs/stdio

So whatever the solution is for /usr/include, it probably should be applied to ${XBPS_CROSS_BASE}/usr/include too.

Member

ebfe commented Dec 22, 2016

FWIW, even before the update (and after the fix) several cross builds sti failed with the sllame error. For example:

https://build.voidlinux.eu/builders/aarch64-musl_builder/builds/3036/steps/shell_3/logs/stdio
https://build.voidlinux.eu/builders/armv6l_builder/builds/29973/steps/shell_3/logs/stdio
https://build.voidlinux.eu/builders/aarch64-musl_builder/builds/3032/steps/shell_3/logs/stdio

So whatever the solution is for /usr/include, it probably should be applied to ${XBPS_CROSS_BASE}/usr/include too.

@pullmoll

This comment has been minimized.

Show comment
Hide comment
@pullmoll

pullmoll Dec 22, 2016

Contributor

The root cause of the problem is, as far as I understand the comments related to it, the sequence or order of -isystem includes. If -isystem /usr/include was the first, or at least before the -isystem for the libstdc++ header file <cstdlib>, things should work.

I'll try to remove -isystem and see if this fixes my problem and makes the packages you listed cross compile.

And who knows, perhaps gcc6.3 (#5400) also fixes the problem.

Contributor

pullmoll commented Dec 22, 2016

The root cause of the problem is, as far as I understand the comments related to it, the sequence or order of -isystem includes. If -isystem /usr/include was the first, or at least before the -isystem for the libstdc++ header file <cstdlib>, things should work.

I'll try to remove -isystem and see if this fixes my problem and makes the packages you listed cross compile.

And who knows, perhaps gcc6.3 (#5400) also fixes the problem.

@pullmoll

This comment has been minimized.

Show comment
Hide comment
@pullmoll

pullmoll Dec 26, 2016

Contributor

The problem persists with gcc-6.3.0. If time permits, I'll take a closer look into the qt5-5.7.1 installed *.pri and *.prf files to identify the one causing the -isystem ${XBPS_CROSS_BASE}/usr/include.

Another quick test: replacing /usr/lib/qt5/mkspecs/common/gcc-base.conf line QMAKE_CFLAGS_ISYSTEM = -isystem with just … = -I makes my project compile.

@ebfe What do you think of patching this file in qt5?
I'm a bit reluctant to such a change without some testing... 🤷‍♂️

Contributor

pullmoll commented Dec 26, 2016

The problem persists with gcc-6.3.0. If time permits, I'll take a closer look into the qt5-5.7.1 installed *.pri and *.prf files to identify the one causing the -isystem ${XBPS_CROSS_BASE}/usr/include.

Another quick test: replacing /usr/lib/qt5/mkspecs/common/gcc-base.conf line QMAKE_CFLAGS_ISYSTEM = -isystem with just … = -I makes my project compile.

@ebfe What do you think of patching this file in qt5?
I'm a bit reluctant to such a change without some testing... 🤷‍♂️

@pullmoll pullmoll closed this in 5f58a00 Dec 31, 2016

@machinekoder

This comment has been minimized.

Show comment
Hide comment
@machinekoder

machinekoder Nov 7, 2017

We had a similar error with QtQuickVcp and fixed it by adding a gcc version dependent qmake command:
https://github.com/qtquickvcp/QtQuickVcp/blob/master/paths.pri#L56-L63

machinekoder commented Nov 7, 2017

We had a similar error with QtQuickVcp and fixed it by adding a gcc version dependent qmake command:
https://github.com/qtquickvcp/QtQuickVcp/blob/master/paths.pri#L56-L63

@machinekoder

This comment has been minimized.

Show comment
Hide comment
@machinekoder

machinekoder Nov 7, 2017

Just in case someone wants to fix it in Qt.

machinekoder commented Nov 7, 2017

Just in case someone wants to fix it in Qt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment