Hi, qt-gui needs neon use-flag because it ignores CFLAGS during configure but not during make. Let me explain: configure adds -mfpu=neon to compile some neon-only code, ignoring my CFLAGS. It succeeds, so then when doing make it will compile neon-only source files, and it will fail because i don't have -mfpu=neon on my CFLAGS. The workaround(i'm pretty sure upstream is happy as it is...) would be using the neon USE-flag(maybe its time to make it global...), to control the -no-neon parameter to configure. Thanks
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 ***
