Changeset 1.67 [1] of qt4-build.eclass besides fixing bug #320851 broke the things by removing the following lines: sed -e "s:QMAKE_CFLAGS_RELEASE.*=.*:QMAKE_CFLAGS_RELEASE=${CFLAGS}:" \ -e "s:QMAKE_CXXFLAGS_RELEASE.*=.*:QMAKE_CXXFLAGS_RELEASE=${CXXFLAGS}:" \ -e "s:QMAKE_LFLAGS_RELEASE.*=.*:QMAKE_LFLAGS_RELEASE=${LDFLAGS}:" \ -i mkspecs/common/g++.conf || die "sed mkspecs/common/g++.conf failed" These lines were removed because the logic was changed as follows. The changeset added sed command to set *FLAGS environment variables in configure script. Configure script then sets qmake cache, which is used for the following compilation. But all config.tests execute qmake with option to ignore the cache. So the logic is broken for config.tests. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt4-build.eclass?r1=1.66&r2=1.67 Reproducible: Always Steps to Reproduce: 1. Set in make.conf LDFLAGS="${LDFLAGS} -Wl,-g" # -g is ignored by linker 2. emerge -avB1 qt-core 3. Ctrl-C after configure stage Actual Results: User *FLAGS are not used during config.tests. For example: x86_64-pc-linux-gnu-g++ -Wl,-O1 -o glib glib.o -L/usr/lib64 -lgthread-2.0 -lrt -lglib-2.0 -pthread Expected Results: User *FLAGS are used during config.tests. For example: x86_64-pc-linux-gnu-g++ -Wl,-g -Wl,-O1 -o glib glib.o -L/usr/lib64 -lgthread-2.0 -lrt -lglib-2.0 -pthread
Created attachment 246618 [details, diff] proposed fix This patch should be applied after attachment 246369 [details, diff] [1] from bug #332669. This patch makes the following changes: 1) export *FLAGS variables in configure to affect config.tests run by it 2) make unix/compile.test and mac/crc.test respect environment variables 3) fix sed command to use insert instead of substitute because it's more straightforward [1] https://bugs.gentoo.org/attachment.cgi?id=246369
I have an Athlon64 box (cpu family 15, model 39, stepping 1, AMD Athlon(tm) 64 Processor 3200+, flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl pni lahf_lm). In a way to test some problems that seem to appear around the use of cpu-extensions (sse*) in some other library, I modified my cflags and use flags so that the use of anything above and including sse3 was to be forbidden. CFLAGS="-O2 -march=native -pipe -mno-sse3 -mno-ssse3 -mno-sse4" USE="... mmx sse sse2 3dnow 3dnowext -sse3 -ssse3 -sse4 -sse4a -sse4_1 ..." However, I found out that with those settings in effect, qt-gui wouldn't build anymore (see attachment). It looks like qt4-build.eclass still doesn't honour user cflags. Also, the above, proposed fix patch doesn't work (can't be applied) anymore. The eclass has changed in the meantime.
Created attachment 295473 [details] Build log of qt-gui-4.7.2
Created attachment 295485 [details, diff] proposed fix rebased against revision 1.103 of qt4-build.eclass
(In reply to comment #2) > It looks like qt4-build.eclass still doesn't honour user cflags. Also, the > above, proposed fix patch doesn't work (can't be applied) anymore. The eclass > has changed in the meantime. Please, try the updated patch (attachment 295485 [details, diff]).
Thanks for responding so quickly! :-) Having applied the patch, build still fails but in some other way. This is the snippet that autodetects the availability of sse3 (the first one which is forbidden in my current cflags setup): sse3 auto-detection... () x86_64-pc-linux-gnu-g++ -c -pipe -O2 -march=native -mno-sse3 -mno-ssse3 -mno-sse4 -msse3 -Wall -W -I../../../mkspecs/linux-g++ -I. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -o sse3.o sse3.cpp x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -o sse3 sse3.o -Wl,-O1 -L/usr/lib64 -lgthread-2.0 -lrt -lglib-2.0 -msse3 sse3 enabled. Seems like the first call of x86_64-pc-linux-gnu-g++ now indeed honours my cflags. The second one doesn't seem to do that. Finally, the stuff still comes to the conclusion that sse3 is available (and acts accordingly, ie. build fails then in a similar way as previously). It's unclear for me at this point whether successfully detecting the presence of sse3 is/was a result of the second gcc call missing user cflags (it actually enables sse3 there explicitely), or even if sse3 was forbidden in any and all possible way in cflags, the autodetect would still report it to be present.
(In reply to comment #6) The first compiler invocation is also wrong. Note that -msse3 is appended *after* -mno-sse3, so it takes precedence and the test is compiled with sse3 enabled.
(In reply to comment #6) > This is the snippet that autodetects the availability of sse3 (the first one > which is forbidden in my current cflags setup): > > sse3 auto-detection... () > x86_64-pc-linux-gnu-g++ -c -pipe -O2 -march=native -mno-sse3 -mno-ssse3 > -mno-sse4 -msse3 -Wall -W -I../../../mkspecs/linux-g++ -I. > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 > -o sse3.o sse3.cpp > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -o sse3 sse3.o > -Wl,-O1 -L/usr/lib64 -lgthread-2.0 -lrt -lglib-2.0 -msse3 > sse3 enabled. > > Seems like the first call of x86_64-pc-linux-gnu-g++ now indeed honours my > cflags. The second one doesn't seem to do that. Finally, the stuff still comes > to the conclusion that sse3 is available (and acts accordingly, ie. build fails > then in a similar way as previously). The first call honours your cflags but appends "-msse3" which takes precedence. The second call doesn't need cflags at all. > It's unclear for me at this point whether successfully detecting the presence > of sse3 is/was a result of the second gcc call missing user cflags (it actually > enables sse3 there explicitely), or even if sse3 was forbidden in any and all > possible way in cflags, the autodetect would still report it to be present. The second call was correct. I'll try to take a look at this a little bit later today.
Created attachment 295539 [details, diff] Add sse* USE-flags to qt4-build.eclass
(In reply to comment #6) > This is the snippet that autodetects the availability of sse3 (the first one > which is forbidden in my current cflags setup): > > sse3 auto-detection... () > x86_64-pc-linux-gnu-g++ -c -pipe -O2 -march=native -mno-sse3 -mno-ssse3 > -mno-sse4 -msse3 -Wall -W -I../../../mkspecs/linux-g++ -I. > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 > -o sse3.o sse3.cpp > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -o sse3 sse3.o > -Wl,-O1 -L/usr/lib64 -lgthread-2.0 -lrt -lglib-2.0 -msse3 > sse3 enabled. Qt4 configure script has special options to disable sse stuff so qt4-build.eclass should make use of them. Could you, please, try to apply the patch from attachment 295539 [details, diff] and run `USE="-sse3" emerge -av1 qt-gui`? Strictly speaking, we should open another bug of qt4-build.eclass not supporting sse-related configure options and move the attachment 295539 [details, diff] there.
*** Bug 382331 has been marked as a duplicate of this bug. ***
*** Bug 345017 has been marked as a duplicate of this bug. ***
*** Bug 384399 has been marked as a duplicate of this bug. ***
*** Bug 366907 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > Qt4 configure script has special options to disable sse stuff so > qt4-build.eclass should make use of them. > Could you, please, try to apply the patch from attachment 295539 [details, diff] [details, diff] and run > `USE="-sse3" emerge -av1 qt-gui`? > > Strictly speaking, we should open another bug of qt4-build.eclass not > supporting sse-related configure options and move the attachment 295539 [details, diff] [details, diff] there. Downloaded the new patch, restored the original qt4-build.eclass and patched it. Attempted re-emerging qt-gui (see attachment). Actually, disabling sse* seems to work. The build process might have finished successfully at this run (I didn't wait until/whether it did). However, the output shows that basically all sse options have been disabled now, despite that sse and sse2 are enabled in the list of default use flags that I had set (ie. in make.conf, see my initial comment). Also, portage seems to complain about missing use flags at the beginning of the configuration process.
Created attachment 295563 [details] Output of emerge after having applied qt4-build_add_sse_use-flags.patch to qt4-build.eclass
(In reply to comment #15) > Actually, disabling sse* seems to work. The build process might have finished > successfully at this run (I didn't wait until/whether it did). Sounds good. > However, the output shows that basically all sse options have been disabled > now, despite that sse and sse2 are enabled in the list of default use flags > that I had set (ie. in make.conf, see my initial comment). Also, portage seems > to complain about missing use flags at the beginning of the configuration > process. Looks like portage hasn't picked up the new IUSE variable from qt4-build.eclass and still uses IUSE variable from generated metadata. Try running `rm /usr/portage/metadata/cache/x11-libs/qt-gui-4.7.2` before running `emerge -av1 qt-gui`
> Looks like portage hasn't picked up the new IUSE variable from qt4-build.eclass > and still uses IUSE variable from generated metadata. > > Try running `rm /usr/portage/metadata/cache/x11-libs/qt-gui-4.7.2` before > running `emerge -av1 qt-gui` Yes, yes. After that, things look completely different. Calculating dependencies... done! [ebuild R ] x11-libs/qt-gui-4.7.2 USE="accessibility cups dbus exceptions glib gtkstyle* mng nas qt3support sse%* sse2%* tiff xinerama (-aqua) -debug -egl -nis -pch -private-headers -raster -sse3% -sse4_1% -sse4_2% -ssse3% -trace" 0 kB The new use flags now do appear, immediately. MMX/3DNOW/SSE/SSE2/SSE3. yes/yes/yes/yes/no SSSE3/SSE4.1/SSE4.2..... no/no/no Perfect, completely in accordance to the use flags set. (Note: also, as expected, the presence of sse3 etc. isn't even attempted to be checked for, previously in the process). compiling[mmx] painting/qdrawhelper_mmx.cpp compiling[mmx3dnow] painting/qdrawhelper_mmx3dnow.cpp compiling[sse3dnow] painting/qdrawhelper_sse3dnow.cpp compiling[sse] painting/qdrawhelper_sse.cpp compiling[sse2] image/qimage_sse2.cpp compiling[sse2] painting/qdrawhelper_sse2.cpp x86_64-pc-linux-gnu-g++ -c ... Perfect. Build is still in progress, but as it looks, the sse* configuration part (so that it takes use flags into account) has been solved. Thanks!
(In reply to comment #18) > Build is still in progress, but as it looks, the sse* configuration part (so > that it takes use flags into account) has been solved. Thanks! Excellent! Thank you for testing!
This should be fixed now, finally. Please sync in a couple of hours and test, reopen if you still have issues. Thanks!
*** Bug 395145 has been marked as a duplicate of this bug. ***
*** Bug 371623 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > This should be fixed now, finally. Please sync in a couple of hours and test, > reopen if you still have issues. Thanks! By the way, what about the patch that adds sse* USE-flags to qt4-build.eclass? Should it be filed as a separate bug?
(In reply to comment #23) > (In reply to comment #20) > > This should be fixed now, finally. Please sync in a couple of hours and test, > > reopen if you still have issues. Thanks! > > By the way, what about the patch that adds sse* USE-flags to qt4-build.eclass? > Should it be filed as a separate bug? No, I won't be adding those flags for now. Using -mno-{mmx,sse*,avx,neon,...} in CXXFLAGS is sufficient, it has worked well in every scenario so far and I'm reasonably satisfied with it.
*** Bug 393425 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > *** Bug 371623 has been marked as a duplicate of this bug. *** ebuild successful detect, that system have not neon and disabled it (ARM Tegra 2). =x11-libs/qt-gui-4.8.0-r1 successful build.
(In reply to comment #26) > (In reply to comment #22) > > *** Bug 371623 has been marked as a duplicate of this bug. *** > > ebuild successful detect, that system have not neon and disabled it (ARM Tegra > 2). =x11-libs/qt-gui-4.8.0-r1 successful build. Great! Thanks for reporting back!
I would like to reopen this bug. I hit it while setting up a Gentoo system for a PentiumIII-based Celeron-M in a VirtualBox-VM. Host CPU is an AMD Phenom II X6. Qt crashed on the target and I was guided in IRC to this bug. I verified that Qt's build-system assumes that the CPI supports all kind of extensions: MMX/3DNOW/SSE/SSE2/SSE3. yes/yes/yes/yes/yes SSSE3/SSE4.1/SSE4.2..... no/yes/yes AVX..................... yes Not even the host-CPU supports AVX. Then I resynced and tried again in the VM, on the host and on an Intel Core2Duo-based host. On all systems (with freshly-synced portage trees) the Qt-build system thinks that AVX is supported (all other extensions too). This is obviosly not correct. On the Core2Duo-system I even deleted /usr/portage/metadata but it didn't help. As I see it this bug has not been fixed or the fix has been reverted or overriden in some way. For your information: mio ~ # sha1sum /usr/portage/eclass/qt4-build.eclass 797794c066cfc328bc6a050254dae61260a3a432 /usr/portage/eclass/qt4-build.eclass
(In reply to comment #28) I said this multiple times already: qt performs a *runtime* detection of cpu capabilities, thus it uses only the routines optimized for the cpu it is running on. I see the same output (from *configure* script, thus NOT runtime) as you, e.g. AVX is enabled although my cpu doesn't support those extensions. Indeed that output refers to what the current compiler is able to *compile*, i.e. if gcc supports building with those particular extensions. Anyway, open a new bug please.