Problem compiling on "Raspbian wheezy"

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] http://www.raspberrypi.org/downloads

Build error:

Updating goal targets…
Considering target file
gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/depend'. Filegr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/depend’ does not
exist.
Considering target file gr-atsc/src/lib/atsci_viterbi_mux.cc'. Filegr-atsc/src/lib/atsci_viterbi_mux.cc’ does not exist.
Considering target file gr-atsc/src/lib/atsci_viterbi_gen'. Finished prerequisites of target filegr-atsc/src/lib/atsci_viterbi_gen’.
No need to remake target gr-atsc/src/lib/atsci_viterbi_gen'. Finished prerequisites of target filegr-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:

[email protected] ~/SW/GR/gnuradio/build $ uname -a
Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012
armv6l GNU/Linux
[email protected] ~/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

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

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

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

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 modevld1.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 modevpadd.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

Hi Nick,

Philip B. pointed me at this patch:

http://lists.gnu.org/archive/html/patch-gnuradio/2012-07/msg00007.html

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