Summary: | x11-libs/qt-core: mkspecs/common/g++.conf overrides upstream QMAKE_CFLAGS_RELEASE | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nikos Chantziaras <realnc> |
Component: | [OLD] Development | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | qt4-build.eclass.patch |
Description
Nikos Chantziaras
2011-01-26 05:13:30 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 This clearly introduces a problem for non-portage builds though. 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. :) (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 Then why is g++.conf modified? 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 Uhm...this means that bug 312689 is back for people with qt >= 4.8, right? (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 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. |