I've just tried to ebuild dev-python/PyQt4-4.7.2 using CFLAGS="-O0 -ggdb". However, the build still used optimization. Looking at the compiler invocations, it seemed that my custom flags were present, but followed by the flags I usually use. stracing the doings of configure.py I found the most likely source to be /usr/share/qt4/mkspecs/common/g++.conf installed by x11-libs/qt-core-4.6.2-r1. That file does mention QMAKE_C[XX]FLAGS_RELEASE with the values that are worrying me here. I wouldn't want compiler flags configured for one package to be forced on other packages as well. I'm not sure how best to avoid this, but if possible I'd welcome a solution to this.
Unfortunately this is standard qmake and sip (PyQt's build system) behaviour. The ebuild already uses eqmake4 to workaround that, plus it passes C(XX)FLAGS to PyQt's configure.py. A build log would be very helpful to find out what's missing, along with CXXFLAGS used to compile Qt4.
Created attachment 226403 [details] PyQt4 build log (In reply to comment #1) > A build log would be very helpful to find out what's missing, > along with CXXFLAGS used to compile Qt4. Build log attached. "-O0 -ggdb" were specified on the command line, while "-march=amdfam10 -O2 -ggdb -pipe" are configured in /etc/make.conf and were used for qt-core. Both of these statements hold for CFLAGS and CXXFLAGS. # qlist -e qt-core | xargs grep -e '-march=amdfam10 -O2 -ggdb -pipe' /usr/share/qt4/mkspecs/common/g++.conf:QMAKE_CFLAGS_RELEASE=-march=... -pipe /usr/share/qt4/mkspecs/common/g++.conf:QMAKE_CXXFLAGS_RELEASE=-march=... -pipe Would it make sense to simply patch that g++.conf in qt-core.c in order to unset these values? Or do you fear that doing so might break anything?
(In reply to comment #2) > [...] patch that g++.conf in qt-core.c [...] "In the qt-core ebuild" is what I had intended to write.
(In reply to comment #2) > Would it make sense to simply patch that g++.conf in qt-core.c in order to > unset these values? Or do you fear that doing so might break anything? > It would break qmake's behaviour for out-of-portage builds. Anyway, qmake is fine: eqmake4 takes care of everything. The problem here is caused by sip's build system: it should ignore mkspecs flags when specific C(XX)FLAGS are passed to configure.py, instead of appending them.
The C(XX)FLAGS part of bug #304971 was fixed quite some time ago (just use >=x11-libs/qt-*-4.6.3 to be sure). Please try again and see if it works correctly now. You have to re-emerge dev-python/sip before PyQt4.
Nope, this isn't completely fixed. /usr/share/qt4/mkspecs/common/g++.conf still adds -O2 to C(XX)FLAGS in release mode.
This can easily be fixed on eclass. If this the only remaining issue I will fix this on qt4-build eclass
(In reply to comment #7) > This can easily be fixed on eclass. If this the only remaining issue I will fix > this on qt4-build eclass > Do we want to change default qmake behaviour then?
Why change it? Just strip -O2 from mkspecs CFLAGS
That "-O2" is upstream default.
Yes so? Do you think qmake will be negatively affected by stripping this flag?
Probably not, but people who use qmake for their own projects may not like the behavioural difference between Gentoo and upstream. I don't know what other distros do.
(In reply to comment #12) > Probably not, but people who use qmake for their own projects may not like the > behavioural difference between Gentoo and upstream. I don't know what other > distros do. > Well, this qmake behavior is violated the Gentoo rules about respecting users' C{XX}FLAGS. This should be the first priority since we are downstream packagers and not upstream developers. I want the rest of the Qt herd to speak up here as well Furthermore, would a special use flag like "qmake-default-cxx" would make sense here?
Ok, I've been thinking a lot on the matter and I've changed my mind :P Furthermore I've just read flameeyes's mail to gentoo-dev-announce and noticed that mkspecs do append -g to QMAKE_*FLAGS_DEBUG, which are used when USE="debug". This is clearly wrong and must be fixed too.
OK so the whole g++ file needs fixing. I will attach a patch here
Created attachment 237081 [details, diff] proposed patch
I suggest the following sed expression: '/^QMAKE_CFLAGS_\(RELEASE\|DEBUG\)/s:+=.*:+=:' Is there anything else we should fix in mkspecs?
I cant think of anything else In 48 hours I am gonna apply Davides' proposal.
Fixed
(In reply to comment #19) > Fixed > Thanks Markos!