Bug 312689 – x11-libs/qt-core forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Martin von Gagern 2010-04-01 19:00:04 UTC]

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.

[Comment 1 Davide Pesavento 2010-04-01 22:18:55 UTC]

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.

[Comment 2 Martin von Gagern 2010-04-03 14:57:37 UTC]

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?

[Comment 3 Martin von Gagern 2010-04-03 14:58:46 UTC]

(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.

[Comment 4 Davide Pesavento 2010-04-03 17:09:43 UTC]

(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.

[Comment 5 Davide Pesavento 2010-06-29 22:52:52 UTC]

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.

[Comment 6 Davide Pesavento 2010-06-30 13:26:39 UTC]

Nope, this isn't completely fixed. /usr/share/qt4/mkspecs/common/g++.conf still adds -O2 to C(XX)FLAGS in release mode.

[Comment 7 Markos Chandras (RETIRED) 2010-06-30 13:29:09 UTC]

This can easily be fixed on eclass. If this the only remaining issue I will fix this on qt4-build eclass

[Comment 8 Davide Pesavento 2010-06-30 14:39:41 UTC]

(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?

[Comment 9 Markos Chandras (RETIRED) 2010-06-30 14:48:15 UTC]

Why change it? Just strip -O2 from mkspecs CFLAGS

[Comment 10 Davide Pesavento 2010-06-30 16:36:53 UTC]

That "-O2" is upstream default.

[Comment 11 Markos Chandras (RETIRED) 2010-06-30 17:18:57 UTC]

Yes so? Do you think qmake will be negatively affected by stripping this flag?

[Comment 12 Davide Pesavento 2010-06-30 17:57:21 UTC]

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.

[Comment 13 Markos Chandras (RETIRED) 2010-06-30 18:29:51 UTC]

(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?

[Comment 14 Davide Pesavento 2010-06-30 21:33:53 UTC]

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.

[Comment 15 Markos Chandras (RETIRED) 2010-06-30 21:39:51 UTC]

OK so the whole g++ file needs fixing. I will attach a patch here

[Comment 16 Markos Chandras (RETIRED) 2010-06-30 21:53:39 UTC]

Created attachment 237081 [details, diff]
proposed patch

[Comment 17 Davide Pesavento 2010-07-01 09:50:32 UTC]

I suggest the following sed expression:
'/^QMAKE_CFLAGS_\(RELEASE\|DEBUG\)/s:+=.*:+=:'

Is there anything else we should fix in mkspecs?

[Comment 18 Markos Chandras (RETIRED) 2010-07-01 14:13:39 UTC]

I cant think of anything else

In 48 hours I am gonna apply Davides' proposal.

[Comment 19 Markos Chandras (RETIRED) 2010-07-03 09:10:14 UTC]

Fixed

[Comment 20 Davide Pesavento 2010-07-03 09:25:05 UTC]

(In reply to comment #19)
> Fixed
> 

Thanks Markos!