Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 336618 - qt4-build.eclass doesn't respect user {C,CXX,LD}FLAGS during config.tests
Summary: qt4-build.eclass doesn't respect user {C,CXX,LD}FLAGS during config.tests
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Highest normal (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
: 345017 366907 371623 382331 384399 393425 395145 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-09 16:08 UTC by Andrey
Modified: 2012-03-04 22:40 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
proposed fix (qt4-build_respect_flags.patch,1.20 KB, patch)
2010-09-09 16:14 UTC, Andrey
Details | Diff
Build log of qt-gui-4.7.2 (qt-gui.build.log,30.49 KB, text/plain)
2011-12-11 15:46 UTC, HÁRSFALVI Levente
Details
proposed fix rebased against revision 1.103 of qt4-build.eclass (qt4-build_respect_flags_r1.103.patch,1.01 KB, patch)
2011-12-11 20:14 UTC, Andrey
Details | Diff
Add sse* USE-flags to qt4-build.eclass (qt4-build_add_sse_use-flags.patch,817 bytes, patch)
2011-12-12 10:53 UTC, Andrey
Details | Diff
Output of emerge after having applied qt4-build_add_sse_use-flags.patch to qt4-build.eclass (qt-gui-comp-log-after-patch-295539.log,27.21 KB, text/plain)
2011-12-12 14:25 UTC, HÁRSFALVI Levente
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey 2010-09-09 16:08:18 UTC
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
Comment 1 Andrey 2010-09-09 16:14:37 UTC
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
Comment 2 HÁRSFALVI Levente 2011-12-11 15:45:03 UTC
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.
Comment 3 HÁRSFALVI Levente 2011-12-11 15:46:54 UTC
Created attachment 295473 [details]
Build log of qt-gui-4.7.2
Comment 4 Andrey 2011-12-11 20:14:35 UTC
Created attachment 295485 [details, diff]
proposed fix rebased against revision 1.103 of qt4-build.eclass
Comment 5 Andrey 2011-12-11 20:15:53 UTC
(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]).
Comment 6 HÁRSFALVI Levente 2011-12-11 22:44:02 UTC
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.
Comment 7 Davide Pesavento gentoo-dev 2011-12-11 23:17:11 UTC
(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.
Comment 8 Andrey 2011-12-12 06:49:37 UTC
(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.
Comment 9 Andrey 2011-12-12 10:53:51 UTC
Created attachment 295539 [details, diff]
Add sse* USE-flags to qt4-build.eclass
Comment 10 Andrey 2011-12-12 10:59:54 UTC
(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.
Comment 11 Davide Pesavento gentoo-dev 2011-12-12 13:37:43 UTC
*** Bug 382331 has been marked as a duplicate of this bug. ***
Comment 12 Davide Pesavento gentoo-dev 2011-12-12 13:39:14 UTC
*** Bug 345017 has been marked as a duplicate of this bug. ***
Comment 13 Davide Pesavento gentoo-dev 2011-12-12 13:41:26 UTC
*** Bug 384399 has been marked as a duplicate of this bug. ***
Comment 14 Davide Pesavento gentoo-dev 2011-12-12 13:48:48 UTC
*** Bug 366907 has been marked as a duplicate of this bug. ***
Comment 15 HÁRSFALVI Levente 2011-12-12 14:23:58 UTC
(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.
Comment 16 HÁRSFALVI Levente 2011-12-12 14:25:24 UTC
Created attachment 295563 [details]
Output of emerge after having applied qt4-build_add_sse_use-flags.patch to qt4-build.eclass
Comment 17 Andrey 2011-12-12 16:20:54 UTC
(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`
Comment 18 HÁRSFALVI Levente 2011-12-12 17:18:01 UTC
> 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!
Comment 19 Andrey 2011-12-12 17:57:24 UTC
(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!
Comment 20 Davide Pesavento gentoo-dev 2011-12-31 00:57:25 UTC
This should be fixed now, finally. Please sync in a couple of hours and test, reopen if you still have issues. Thanks!
Comment 21 Thomas Sachau gentoo-dev 2011-12-31 14:41:31 UTC
*** Bug 395145 has been marked as a duplicate of this bug. ***
Comment 22 Davide Pesavento gentoo-dev 2012-01-04 01:26:06 UTC
*** Bug 371623 has been marked as a duplicate of this bug. ***
Comment 23 Andrey 2012-01-04 09:05:12 UTC
(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?
Comment 24 Davide Pesavento gentoo-dev 2012-01-04 11:36:59 UTC
(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.
Comment 25 Raúl Porcel (RETIRED) gentoo-dev 2012-02-10 19:39:37 UTC
*** Bug 393425 has been marked as a duplicate of this bug. ***
Comment 26 Denis I. Polukarov 2012-02-11 10:51:03 UTC
(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.
Comment 27 Davide Pesavento gentoo-dev 2012-02-11 11:10:21 UTC
(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!
Comment 28 jannis 2012-03-04 17:37:54 UTC
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
Comment 29 Davide Pesavento gentoo-dev 2012-03-04 22:40:55 UTC
(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.