At the start of building of Qt, while qmake is being built, CPPFLAGS, CXXFLAGS, ASFLAGS and LDFLAGS are ignored. (Also CPPFLAGS and ASFLAGS are always ignored.)
Created attachment 114405 [details, diff] qt-FLAGS.patch
Created attachment 115090 [details, diff] qt-FLAGS.patch Updated patch.
These bugs aren't related.
(In reply to comment #3) > These bugs aren't related. But could you explain why users must wait very longly before bug reports with ready, good patches are resolved?
because this is a completely voluntary effort of which we could use more help.
Created attachment 118042 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 119055 [details, diff] qt-FLAGS.patch Updated patch.
I've applied your patch to 4.3.0_rc1. I'm hesitant to do it to older versions just because of the compilation error impact it might have, but we can try it out for the 4.3 series and the future.
(In reply to comment #8) > I've applied your patch to 4.3.0_rc1. Thanks. > I'm hesitant to do it to older versions just because of the compilation error > impact it might have I was rebuilding older version many times when updates were available and it never caused any compilation error. Actually any occurrence of compilation error caused by optimizing qmake is rather impossible because in this case qmake is only used to process data from *.pr[io] and *.conf files (and environment?) into Makefiles. So you can safely apply at least the qt-3.3.8-r2 part of my patch (I don't have qt-4.{2.3-r1,3.0_beta1} installed so I don't care about them). P.S. I yesterday discovered that configure script from Qt >=4.3.0_beta1 has new options "-optimized-qmake" and "-no-optimized-qmake" so maybe even upstream realized that not optimizing qmake was error. However "-no-optimized-qmake" seems to be still default. But these options weren't tested by me so don't change qt-4.3.0_rc1.ebuild, please, as current version of qt-4.3.0_rc1.ebuild surely works correctly.
Created attachment 119841 [details, diff] qt-FLAGS.patch Updated patch. Patching a fragment of qt-4.3.0_rc1.ebuild is only to keep consistency with other fragments of this ebuild. Entire KDE, KOffice, K3b etc. build correctly with qmake optimized, so you can safely apply this patch. (In reply to comment #9) > "-optimized-qmake" Unfortunately this option ignores LDFLAGS.
Created attachment 121503 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 126753 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 127185 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 127303 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 131537 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 132484 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 138098 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 141511 [details, diff] qt-FLAGS.patch Updated patch. Currently all ebuilds using qt4-build.eclass completely ignore LDFLAGS. It should be fixed.
All Qt 4.4.0_beta1 ebuilds are fixed.
Created attachment 161527 [details, diff] qt-FLAGS.patch Updated patch.
x11-libs/qt-core-4.4.0: * QA Notice: Files built without respecting LDFLAGS have been detected * Please include this file in your report: * /var/tmp/portage/x11-libs/qt-core-4.4.0/temp/scanelf-ignored-LDFLAGS.log * /usr/bin/qmake
Created attachment 162409 [details, diff] qt-FLAGS.patch Updated patch.
Created attachment 165848 [details, diff] qt-FLAGS.patch Updated patch.
qt-3.3.8b is fixed now, still need to do qt-4
Created attachment 182051 [details, diff] qt-FLAGS.patch Updated patch.
(In reply to comment #25) > Created an attachment (id=182051) [edit] > qt-FLAGS.patch > > Updated patch. > That should go into qt4-build eclass . There is no point in doing this only for qt-core right?
Ok, both qt-core-4.5.0_rc1 ebuild and eclass fixed on cvs This bug can now close :) Re-open if needed
