discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Problem compiling on "Raspbian wheezy".


From: Andrew Back
Subject: Re: [Discuss-gnuradio] Problem compiling on "Raspbian wheezy".
Date: Fri, 20 Jul 2012 21:11:44 +0100

Hi Nick,

Philip Balister 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 Foster <address@hidden> wrote:
> 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 Thu, Jul 19, 2012 at 10:36 PM, Andrew Back <address@hidden>
> wrote:
>>
>> On 19 July 2012 18:06, Nick Foster <address@hidden> 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 Back
>> http://carrierdetect.com
>
>



-- 
Andrew Back
http://carrierdetect.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]