Bug 649264 – dev-qt/qtgui - In file included from image/qimage_ssse3.cpp:40: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/cstdlib:75:15: fatal error: stdlib.h: No such file or directory

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description kuzetsa CatSwarm (kuza for short) 2018-03-01 19:55:56 UTC]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c3

as I understand, the recipe for failure seems to involve mixing -I {some_path} with -isystem, and also  #include_next <stdlib.h>

tested packages:

dev-qt/qtgui-5.7.1-r1
dev-qt/qtopengl-5.7.1
dev-qt/qtprintsupport-5.7.1
dev-qt/qtwidgets-5.7.1

also tried unstable slot dev-qt/qtgui:5/5.9 (same issue)

package list is likely NOT exhaustive.

similar to gentoo bug #594672

unsure if this bug was triggered by upgrading to gcc-7.3.0, but this is when the regression began (was previously able to build gcc

[Comment 1 kuzetsa CatSwarm (kuza for short) 2018-03-01 19:57:30 UTC]

Created attachment 521744 [details]
build.log for qtgui-5.9.4-r3

[Comment 2 Mike Gilbert 2018-03-01 22:13:27 UTC]

You have some package installed that has a pkgconfig file with Cflags: -I/usr/include/ (note the trailing slash). This is the cause of the problem here, since pkg-config does not filter that path out.

Please grep /usr/lib64/pkgconfig/*.pc for "-I/usr/include/".

[Comment 3 Mike Gilbert 2018-03-01 22:50:09 UTC]

*** Bug 649268 has been marked as a duplicate of this bug. ***

[Comment 4 kuzetsa CatSwarm (kuza for short) 2018-03-01 23:03:36 UTC]

(In reply to Mike Gilbert from comment #2)
> You have some package installed that has a pkgconfig file with Cflags:
> -I/usr/include/ (note the trailing slash). This is the cause of the problem
> here, since pkg-config does not filter that path out.
> 
> Please grep /usr/lib64/pkgconfig/*.pc for "-I/usr/include/".

prior to fixing this issue (caused by meson)

/usr/lib64/pkgconfig/xshmfence.pc:Cflags: -I${includedir} -I/usr/include/

... a file which is owned by x11-libs/libxshmfence

fixing the issue (bad meson version) and rebuilding the relevant deps, the same grep command shows:

(((no output, because nothing matching the pattern)))

[Comment 5 Jeroen Roovers (RETIRED) 2018-03-02 07:29:31 UTC]

[1] gives a workaround: "[A]ppend QMAKE_CFLAGS_ISYSTEM= after the other configure arguments, that way no file editing is needed."


[1] https://bugreports.qt.io/browse/QTBUG-53367?focusedCommentId=370122&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-370122

[Comment 6 Jeroen Roovers (RETIRED) 2018-03-02 07:34:56 UTC]

(In reply to Jeroen Roovers from comment #5)

diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass
index b664edb611b..2dfbf4db055 100644
--- a/eclass/qt5-build.eclass
+++ b/eclass/qt5-build.eclass
@@ -772,6 +772,7 @@ qt5_qmake() {
                QMAKE_LFLAGS_RELEASE= \
                QMAKE_LFLAGS_DEBUG= \
                "${myqmakeargs[@]}" \
+               QMAKE_CFLAGS_ISYSTEM= \
                || die "qmake failed (${projectdir#${S}/})"
 }


So that? Seems to work for dev-qt/qtgui.

[Comment 7 Jeroen Roovers (RETIRED) 2018-03-02 08:56:55 UTC]

Oh, but that doesn't work for qtmultimedia:

 * Running qt5_qmake
Info: creating stash file /home/portage/dev-qt/qtmultimedia-5.9.4-r1/work/qtmultimedia-opensource-src-5.9.4/.qmake.stash
Info: creating cache file /home/portage/dev-qt/qtmultimedia-5.9.4-r1/work/qtmultimedia-opensource-src-5.9.4/.qmake.cache
ERROR: Assigning unknown variable 'QMAKE_CFLAGS_ISYSTEM' on command line.

[Comment 8 Michael Palimaka (kensington) 2018-03-02 10:46:56 UTC]

I wasn't able to reproduce on a fully-updated ~arch system.

kuzetsa, was the issue fixed for you when xshmfence.pc no longer contained the trailing slash?

jer, do you also have .pc files with trailing slash?

[Comment 9 Mike Gilbert 2018-03-02 14:30:52 UTC]

It's also worth looking for files in /usr/share/pkgconfig; the new x11-base/xorg-proto package installs files there, and will generate bad paths with a trailing slash if built using <dev-util/meson-0.44.1.

[Comment 10 kuzetsa CatSwarm (kuza for short) 2018-03-02 18:27:44 UTC]

(In reply to Michael Palimaka (kensington) from comment #8)
> I wasn't able to reproduce on a fully-updated ~arch system.
> 
> kuzetsa, was the issue fixed for you when xshmfence.pc no longer contained
> the trailing slash?
> 
> jer, do you also have .pc files with trailing slash?

yes. I did (past tense) as-per comment #4

it went away after xproto / and xshmfence.pc were clean versions
(I forget which was created as a result of the old meson version)

[Comment 11 kuzetsa CatSwarm (kuza for short) 2018-03-02 18:33:53 UTC]

(In reply to Michael Palimaka (kensington) from comment #8)
> I wasn't able to reproduce on a fully-updated ~arch system.
> 
> kuzetsa, was the issue fixed for you when xshmfence.pc no longer contained
> the trailing slash?
> 

yes. sorry I had intended to be more clear (comment #4) but was a tad hasty.

the problem is resolved / no more qt build issues now that Qt is no longer seeing the faulty xshmfence.pc

the steps to fix were:

1) update meson
2) rebuild some xproto things (I forget which one specifically was "faulty" / weird because of meson)
3) rebuild x11-libs/libxshmfenc (which will no longer generate a bad xshmfence.pc after step 2 is done)

I would need to downgrade meson to reproduce the particular xproto.pc (I think that was filename) which led to a bad xshmfence.pc (but now that all of the qt packages are done building & no longer error, I'd rather NOT intentionally cause a regression)

[Comment 12 Michael Palimaka (kensington) 2018-03-02 23:48:30 UTC]

*** Bug 649046 has been marked as a duplicate of this bug. ***

[Comment 13 Jeroen Roovers (RETIRED) 2018-03-06 22:06:28 UTC]

Also note that you then need to go in and fix previously built qt* packages. On initially having qtgui installed, I found that it had picked up those compiler flags and neatly stored them in /usr/lib64/qt5/mkspecs/modules/qt_lib_gui_private.pri .

[Comment 14 Reto Gantenbein (ganto) 2018-03-11 17:05:38 UTC]

I had the same build issue with dev-qt/qtgui-5.9.4-r3 using sys-devel/gcc-6.4.0-r1. As previously said by others, fixing the xshmfence.pc resolved the build failure for me too.

(In reply to kuzetsa from comment #11)
> the steps to fix were:
> 
> 1) update meson
> 2) rebuild some xproto things (I forget which one specifically was "faulty"
> / weird because of meson)
> 3) rebuild x11-libs/libxshmfenc (which will no longer generate a bad
> xshmfence.pc after step 2 is done)

The package in question is x11-base/xorg-proto. After rebuilding this and libxshmfence, qtgui would compile successfully.

[Comment 15 Richard Freeman 2018-04-22 10:32:37 UTC]

I ran into the same issue when building www-client/chromium-66.0.3359.117.  The fix in comment 14 addressed it.  I just figured I'd mention it since we could get more users running into this with the security bump.

[Comment 16 Aaron W. Swenson 2018-04-28 11:10:14 UTC]

(In reply to Reto Gantenbein (ganto) from comment #14)
> I had the same build issue with dev-qt/qtgui-5.9.4-r3 using
> sys-devel/gcc-6.4.0-r1. As previously said by others, fixing the
> xshmfence.pc resolved the build failure for me too.
> 
> (In reply to kuzetsa from comment #11)
> > the steps to fix were:
> > 
> > 1) update meson
> > 2) rebuild some xproto things (I forget which one specifically was "faulty"
> > / weird because of meson)
> > 3) rebuild x11-libs/libxshmfenc (which will no longer generate a bad
> > xshmfence.pc after step 2 is done)
> 
> The package in question is x11-base/xorg-proto. After rebuilding this and
> libxshmfence, qtgui would compile successfully.

This did the trick for me.

Updated meson, rebuilt libxshmfence, rebuilt x11-base/xorg-proto, and rebuilt libxshmfence again (not sure this last one was necessary, but it's what I did).

[Comment 17 Andreas Sturmlechner 2018-07-08 09:46:58 UTC]

*** Bug 660688 has been marked as a duplicate of this bug. ***

[Comment 18 Zac Medico 2018-07-23 02:49:59 UTC]

I hit this upgrading a system that hadn't been updated since late January. The bad version of meson for me was meson-0.43.0:

Sun Jan 28 00:53:18 2018 >>> dev-util/meson-0.43.0
Sun Jul 22 03:43:06 2018 >>> dev-util/meson-0.46.1

Maybe we could bump the minimum meson version in meson.eclass to solve this?

[Comment 19 Zac Medico 2018-07-23 03:36:32 UTC]

(In reply to Zac Medico from comment #18)
> I hit this upgrading a system that hadn't been updated since late January.
> The bad version of meson for me was meson-0.43.0:
> 
> Sun Jan 28 00:53:18 2018 >>> dev-util/meson-0.43.0
> Sun Jul 22 03:43:06 2018 >>> dev-util/meson-0.46.1
> 
> Maybe we could bump the minimum meson version in meson.eclass to solve this?

Patch sent for review:

https://archives.gentoo.org/gentoo-dev/message/30cba765620e55b90eae9d3f2a223d94

[Comment 20 Larry the Git Cow 2018-07-23 20:27:48 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bbe649a35dc8e06e55abfdf8e98a743d1e50d5a0

commit bbe649a35dc8e06e55abfdf8e98a743d1e50d5a0
Author:     Zac Medico <[e-mail]>
AuthorDate: 2018-07-23 20:17:34 +0000
Commit:     Zac Medico <[e-mail]>
CommitDate: 2018-07-23 20:27:39 +0000

    meson.eclass: require at least meson-0.45.1
    
    Require newer meson in order to avoid build failures triggered
    new meson is not installed soon enough. For example, I experienced
    bug 649264 because I upgraded xorg-proto and libxshmfence packages
    before meson.
    
    Although meson-0.44.1 is enough to solve bug 649264, Mike Gilbert
    suggests to require at least meson-0.45.1, since this version is
    the latest stable on all archs.
    
    Closes: https://bugs.gentoo.org/649264
    Reviewed-by: Mart Raudsepp <[e-mail]>
    Reviewed-by: Mike Gilbert <[e-mail]>

 eclass/meson.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)