Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 352778 - x11-libs/qt-core: mkspecs/common/g++.conf overrides upstream QMAKE_CFLAGS_RELEASE
Summary: x11-libs/qt-core: mkspecs/common/g++.conf overrides upstream QMAKE_CFLAGS_REL...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-26 05:13 UTC by Nikos Chantziaras
Modified: 2012-05-07 21:46 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
qt4-build.eclass.patch (qt4-build.eclass.patch,551 bytes, patch)
2012-04-04 19:48 UTC, Michael Palimaka (kensington)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Chantziaras 2011-01-26 05:13:30 UTC
When trying to manually build Qt applications that use qmake, no CFLAGS or CXXFLAGS are used in the generated Makefile when using x11-libs/qt-core. When using a Qt built and installed outside of portage, it works OK. For example, "qmake CONFIG+=release" will use "-O2".

It seems the portage-installed Qt is missing some files in mkspecs, like "common/g++.conf" which exists in the manually built Qt and contains the correct CFLAGS.

I'm not sure if this is specific to 4.7.1-r1.
Comment 1 Davide Pesavento gentoo-dev 2011-01-27 14:30:15 UTC
mkspecs/common/g++.conf is installed, but qt4-build.eclass strips -O2 from QMAKE_CFLAGS_RELEASE, that's why Makefiles generated by qmake don't have it.

This was decided some time ago to solve issues like bug #312689
Comment 2 Nikos Chantziaras 2011-01-27 14:38:52 UTC
This clearly introduces a problem for non-portage builds though.
Comment 3 Nikos Chantziaras 2011-01-27 14:52:21 UTC
Stripping this flag is the wrong thing to do.  You are supposed to supply your own flags if you don't want the defaults.  Upstream provides for this.  Non-portage packages using qmake will now silently build without optimization if you modify g++.conf.

The portage eclass should supply the flags set in the user's make.conf to qmake.  For example, if you don't want the default optimization flags, set your own by invoking qmake like this:

qmake QMAKE_CFLAGS_RELEASE=[your CFLAGS] QMAKE_CXXFLAGS_RELEASE=[your CXXFLAGS]

There is no reason for modifying g++.conf and breaking upstream behavior. :)
Comment 4 Davide Pesavento gentoo-dev 2011-01-27 16:30:04 UTC
(In reply to comment #3)
> The portage eclass should supply the flags set in the user's make.conf to
> qmake.  For example, if you don't want the default optimization flags, set your
> own by invoking qmake like this:
> 
> qmake QMAKE_CFLAGS_RELEASE=[your CFLAGS] QMAKE_CXXFLAGS_RELEASE=[your CXXFLAGS]
> 

This is already done by eqmake4() in qt4{,-r2}.eclass
Comment 5 Nikos Chantziaras 2011-01-27 16:38:33 UTC
Then why is g++.conf modified?
Comment 6 Michael Palimaka (kensington) gentoo-dev 2012-04-04 19:48:43 UTC
Created attachment 307827 [details, diff]
qt4-build.eclass.patch

It appears that this bug no longer exists. The change introduced in bug #312689 [1] no longer does anything - g++.conf now simply includes other files.

When running in-portage builds, CFLAGS are respected (for the most part, see bug #361303). Performing an out-of-portage build with CONFIG+=release, I saw upstream flags: -pipe -O2 -Wall.

Finally, attached is a patch to remove the now-redundant change introduced in [1].

[1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt4-build.eclass?r1=1.74&r2=1.75
Comment 7 Davide Pesavento gentoo-dev 2012-04-19 23:05:23 UTC
Uhm...this means that bug 312689 is back for people with qt >= 4.8, right?
Comment 8 Michael Palimaka (kensington) gentoo-dev 2012-04-21 17:55:30 UTC
(In reply to comment #7)
> Uhm...this means that bug 312689 is back for people with qt >= 4.8, right?

Sort of.

It it my understanding of that bug as well as bug #304971 that the CFLAGS used to compile qt-core somehow ended up in /usr/share/qt4/mkspecs/ - which appears to no longer be the case.

That is good, but since configure.py calls qmake directly, upstream's default RELEASE flags are appended instead.

So, mkspecs/qt-core and standard qmake packages should be fixed, leaving just PyQt4. I pushed a fix[1] to the overlay which hopefully kills the last of these CFLAGS bugs for good.

[1]: http://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=commitdiff;h=e141176cba4d5c097b09b94446db9f6dc17477e3
Comment 9 Davide Pesavento gentoo-dev 2012-05-07 21:46:12 UTC
I changed qt4-build.eclass to perform the sed only for Qt < 4.8.
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt4-build.eclass?r1=1.127&r2=1.128&view=patch

The sip/PyQt4 issue will be discussed in a separate bug.