Problem compiling on "Raspbian wheezy"

bfsog · July 19, 2012, 2:10pm

Hello,

I’m trying to compile a fresh copy of GNU Radio from Git on a
Raspberry Pi running Raspbian wheezy [1] and encountering some
problems. I seem to have got round the first by setting -mfpu neon
when running cmake:

cmake -DCMAKE_CXX_FLAGS:STRING="-mfpu=neon"

-DCMAKE_C_FLAGS:STRING=“-mfpu=neon” …/

But now it’s crashing out at 68% when “Generating
atsci_viterbi_mux.cc” paste below.

Can anyone suggest a possible fix? And let me know if more
debug/environment information is required.

Regards,

Andrew

[1] Raspberry Pi OS – Raspberry Pi

Build error:

Updating goal targets…
Considering target file
gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/depend'. File gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/depend’ does not
exist.
Considering target file gr-atsc/src/lib/atsci_viterbi_mux.cc'. File gr-atsc/src/lib/atsci_viterbi_mux.cc’ does not exist.
Considering target file gr-atsc/src/lib/atsci_viterbi_gen'. Finished prerequisites of target file gr-atsc/src/lib/atsci_viterbi_gen’.
No need to remake target gr-atsc/src/lib/atsci_viterbi_gen'. Finished prerequisites of target file gr-atsc/src/lib/atsci_viterbi_mux.cc’.
Must remake target `gr-atsc/src/lib/atsci_viterbi_mux.cc’.
[ 68%] Generating atsci_viterbi_mux.cc
Illegal instruction
make[2]: *** [gr-atsc/src/lib/atsci_viterbi_mux.cc] Error 132
make[1]: *** [gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/all] Error 2
make: *** [all] Error 2

Environment:

pi@raspberrypi ~/SW/GR/gnuradio/build $ uname -a
Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012
armv6l GNU/Linux
pi@raspberrypi ~/SW/GR/gnuradio/build $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: …/src/configure -v --with-pkgversion=‘Debian
4.6.3-8+rpi1’ --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
–enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
–program-suffix=-4.6 --enable-shared --enable-linker-build-id
–with-system-zlib --libexecdir=/usr/lib --without-included-gettext
–enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
–libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
–enable-libstdcxx-debug --enable-libstdcxx-time=yes
–enable-gnu-unique-object --enable-plugin --enable-objc-gc
–disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp
–with-float=hard --enable-checking=release
–build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
–target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-8+rpi1)

–
Andrew B.
http://carrierdetect.com

bfsog · July 19, 2012, 2:27pm

On Thu, Jul 19, 2012 at 01:09:22PM +0100, Andrew B. wrote:

But now it’s crashing out at 68% when “Generating
atsci_viterbi_mux.cc” — paste below.

Can anyone suggest a possible fix? And let me know if more
debug/environment information is required.

Until Phil comes up with something better, you can try building GR
without ATSC support (unless that’s exactly what you were going for, you
probably won’t need the ATSC module for anything else).

$ cmake -DENABLE_GR_ATSC=OFF …/

At least that would narrow down the troubleshooting.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

bfsog · July 19, 2012, 7:07pm

The --mfpu=neon flag is inappropriate for Raspberry Pi, which lacks
NEON. I
suspect Gnuradio’s build system is detecting ARM and assuming NEON
exists.
I know gr-filter is doing this (see
gnuradio/gnuradio-core/src/lib/filter/CMakeLists.txt
line 212).

Some rudimentary checking for NEON is probably appropriate. Volk is
already
doing this, although its checks are at runtime so they look a little
different than a CMake script would.

–n

bfsog · July 20, 2012, 4:47pm

It’s still detecting and attempting to compile NEON vector instructions
in
gr-filter; there are NEON assembly routines in there intended to speed
up
E100 filter operations. I don’t know what string CMake should be
checking
for there, but “arm” is inappropriate, since it makes no attempt to
determine if the ARM has NEON support or not. We should probably write a
“FindNeon.cmake” to set this more appropriately.

In the meantime, you can cut out that entire section of filter stuff
starting at gnuradio-core/src/lib/filter/CMakeLists.txt line 212.

–n

bfsog · July 20, 2012, 7:37am

On 19 July 2012 18:06, Nick F. [email protected] wrote:

The --mfpu=neon flag is inappropriate for Raspberry Pi, which lacks NEON. I
suspect Gnuradio’s build system is detecting ARM and assuming NEON exists. I
know gr-filter is doing this (see
gnuradio/gnuradio-core/src/lib/filter/CMakeLists.txt line 212).

Some rudimentary checking for NEON is probably appropriate. Volk is already
doing this, although its checks are at runtime so they look a little
different than a CMake script would.

So I found [1] what appears to be the correct flags and set these:

cmake -DCMAKE_CXX_FLAGS:STRING=“-march=armv6 -mfpu=vfp
-mfloat-abi=hard” -DCMAKE_C_FLAGS:STRING=“-march=armv6 -mfpu=vfp
-mfloat-abi=hard” …/

But now the build fails even earlier with gnuradio-core:

[ 17%] Building CXX object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_armv7_a.cc.o
[ 17%] Building C object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o
/tmp/ccHDAfuu.s: Assembler messages:
/tmp/ccHDAfuu.s:26: Error: selected FPU does not support instruction
– vmov.f32 q8,#0.0' /tmp/ccHDAfuu.s:27: Error: selected FPU does not support instruction -- vmov.f32 q9,#0.0’
/tmp/ccHDAfuu.s:30: Error: selected processor does not support ARM
mode vld1.32 {d0,d1,d2,d3},[r0]!' /tmp/ccHDAfuu.s:31: Error: selected processor does not support ARM mode vld1.32 {d4,d5,d6,d7},[r1]!’
/tmp/ccHDAfuu.s:32: Error: selected FPU does not support instruction
– vmla.f32 q8,q0,q2' /tmp/ccHDAfuu.s:33: Error: selected FPU does not support instruction -- vmla.f32 q9,q1,q3’
/tmp/ccHDAfuu.s:35: Error: selected FPU does not support instruction
– vadd.f32 q8,q8,q9' /tmp/ccHDAfuu.s:36: Error: selected processor does not support ARM mode vpadd.f32 d0,d16,d17’
make[2]: ***
[gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
Error 1
make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
Error 2
make: *** [all] Error 2

Which IIRC is around where it was failing when I did not set any flags
at all with Cmake.

Regards,

Andrew

[1]
http://www.raspbian.org/RaspbianFAQ#What_compilation_options_should_be_set_Raspbian_code.3F

–
Andrew B.
http://carrierdetect.com

bfsog · July 20, 2012, 10:14pm

Hi Nick,

Philip B. pointed me at this patch:

[Patch-gnuradio] Add possibility to disable NEON optimisation on ARM

I applied this and then ran cmake with:

cmake -Dhave_mfpu_neon=0 -DCMAKE_CXX_FLAGS:STRING=“-march=armv6
-mfpu=vfp -mfloat-abi=hard” -DCMAKE_C_FLAGS:STRING=“-march=armv6
-mfpu=vfp -mfloat-abi=hard” …/

And the build was successful. Many thanks to all who have helped!

Is there an easy way to tell if this will now be using hardware floating
point?

Regards,

Andrew

On 20 July 2012 15:46, Nick F. [email protected] wrote:

–n

know gr-filter is doing this (see
-mfloat-abi=hard" -DCMAKE_C_FLAGS:STRING="-march=armv6 -mfpu=vfp
/tmp/ccHDAfuu.s: Assembler messages:
/tmp/ccHDAfuu.s:33: Error: selected FPU does not support instruction
make: *** [all] Error 2

–
Andrew B.
http://carrierdetect.com

–
Andrew B.
http://carrierdetect.com