Summary: | x11-libs/qt-gui needs neon USE-flag | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Raúl Porcel (RETIRED) <armin76> |
Component: | New packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | arm, gavinlee303, siarhei.siamashka, steev |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Raúl Porcel (RETIRED)
2011-12-06 18:07:32 UTC
The build failure doesn't need this workaround, I think it can be properly solved by fixing bug #336618. On the other hand, would a "neon" USE flag be useful anyway, e.g. to avoid autodetection of cpu features for cross-compilation? If there's a -mno-neon gcc switch, similar to -mno-sse and friends, it shouldn't be necessary because you can add that switch to your C(XX)FLAGS and, assuming bug #336618 fixed, autodetection will fail and qt-gui will build without neon support. Are there any other cases I'm unaware of? Bug #336618 has been fixed. Is a "neon" USE flag still needed? I'll let you know once i can try it out Was just emerging x11-libs/qt-gui-4.8.0-r2 and noticed this. Timestamp of tree: Thu, 09 Feb 2012 01:45:01 +0000 CXXFLAGS="-O2 -ggdb -march=armv7-a -mfpu=vfpv3 -mfloat-abi=softfp -pipe" ----8<---- neon auto-detection... () armv7a-unknown-linux-gnueabi-g++ -c -pipe -mfpu=neon -O2 -ggdb -march=armv7-a -mfpu=vfpv3 -mfloat-abi=softfp -pipe -O2 -Wall -W -I../../../mkspecs/linux-g++ -I. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -o neon.o neon.cpp In file included from neon.cpp:42:0: /usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/include/arm_neon.h:32:2: error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h neon.cpp: In function 'int main(int, char**)': neon.cpp:46:5: error: 'int32x4_t' was not declared in this scope neon.cpp:46:15: error: expected ';' before 'null' neon.cpp:49:29: error: 'null' was not declared in this scope neon.cpp:49:36: error: 'vst1q_lane_s32' was not declared in this scope gmake: *** [neon.o] Error 1 neon disabled. ----8<---- seems that the -mfpu=vfpv3 after the -mfpu=neon causes neon test to fail (In reply to comment #4) > seems that the -mfpu=vfpv3 after the -mfpu=neon causes neon test to fail Sure, because the last -mfpu option takes precedence over earlier ones. Isn't that expected? (Please CC yourself when commenting on a bug) Sorry, thought I added CC. Was not clear that I actually wanted neon optimisation, not sure if -mfpu=neon is good in make.conf. I have a pandaboard and that supports vfpv3 and neon, could add -mfpu=neon in flags at /etc/portage/env/x11-libs/qt-gui so it's no bother just thought I add that info here after seeing the tests fail. Thanks. (In reply to comment #7) > Sorry, thought I added CC. > > Was not clear that I actually wanted neon optimisation, not sure if -mfpu=neon > is good in make.conf. > I have a pandaboard and that supports vfpv3 and neon, could add -mfpu=neon in > flags at /etc/portage/env/x11-libs/qt-gui so it's no bother just thought I add > that info here after seeing the tests fail. Thanks. As far as I understand, -mfpu=neon implies -mfpu=vfpv3, so you could just put the former in your make.conf Okay, with the fix from bug #336618 this is fixed as well, so i'm marking it as a duplicate. Gavin, Davide is right, neon implies vfpv3, in fact neon is an implementation of vfpv3. Although i don't know of a SoC with vfpv3 that doesn't have neon(tegra has vfpv3-d16) *** This bug has been marked as a duplicate of bug 336618 *** |