On Fri, 2012-12-07 at 14:20 +0100, Peter Meerwald wrote: > Hello, > > > I've been trying to get this to build on Fedora 18 on ARM to test the > > UCM support and I'm running into an issue with what appears to be the > > build ignoring the distro CFLAGS. Basically we don't currently build > > for NEON as it's not guaranteed to be available on all platforms but > > rather then rely on optimised code paths and run time detection for > > NEON use. > > > I'm running into the following error where it's making an assumption > > that NEON is there so trying to use it but as we're not using it the > > build is failing. > > > libtool: compile: armv7hl-redhat-linux-gnueabi-gcc -std=gnu99 > > -DHAVE_CONFIG_H -I. -I.. -DFASTPATH -I../src -I../src/modules > > -I../src/modules -pthread > > -DPA_ALSA_PATHS_DIR=\"/usr/share/pulseaudio/alsa-mixer/paths\" > > -DPA_ALSA_PROFILE_SETS_DIR=\"/usr/share/pulseaudio/alsa-mixer/profile-sets\" > > -mfpu=neon -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > > -fstack-protector --param=ssp-buffer-size=4 -march=armv7-a > > -mfpu=vfpv3-d16 -mfloat-abi=hard -W -Wextra -Wno-long-long > > -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 > > -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs > > -Wformat-nonliteral -Wpointer-arith -Winit-self > > -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes > > -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow > > -Wendif-labels -Wcast-align -Wstrict-aliasing -Wwrite-strings > > -Wno-unused-parameter -ffast-math -fno-common > > -fdiagnostics-show-option -c pulsecore/sconv_neon.c -fPIC -DPIC -o > > .libs/libpulsecore_sconv_neon_la-sconv_neon.o > > In file included from pulsecore/sconv_neon.c:30:0: > > /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2/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 > > your compiler invokation has -mfpu=neon followed by -mfpu=vfpv3-d16 (the > later option overrides the previous), hence NEON is not available > > I think the PulseAudio's configure.ac (snippet below) is incorrect; it > merely checks if the -mfpu=neon is understood as a compiler option, but > not if it actually works (e.g. by #including arm_neon.h) > > AS_IF([test "x$enable_neon_opt" != "xno"], > [save_CFLAGS="$CFLAGS"; CFLAGS="$CFLAGS -mfpu=neon" > AC_COMPILE_IFELSE( > AC_LANG_PROGRAM([], []), > [ > HAVE_NEON=1 > NEON_CFLAGS="-mfpu=neon" > ], > [ > HAVE_NEON=0 > NEON_CFLAGS= > ]) > CFLAGS="$save_CFLAGS" > ], > [HAVE_NEON=0]) > > a second issue is may be in the compiler invokation: -mfpu=neon is the > one of the first options (coming from NEON_CFLAGS), followed by those > probably coming from the toolchain/cross-compilation environment Good point -- making the program to be compiled a '#include <arm_neon.h>' should make the automagic check work better. In the mean time, as Jan points out, --disable-neon-opt will do the trick. > src/Makefile.am has: > > if HAVE_NEON > noinst_LTLIBRARIES += libpulsecore_sconv_neon.la > libpulsecore_sconv_neon_la_SOURCES = pulsecore/sconv_neon.c > libpulsecore_sconv_neon_la_CFLAGS = $(AM_CFLAGS) $(NEON_CFLAGS) > libpulsecore_ at PA_MAJORMINOR@_la_LIBADD += libpulsecore_sconv_neon.la > endif > > so NEON_CFLAGS (determined by configure) is supposed to override whatever > your compilation environment provides; however, this does see so work as > -mfpu=vfpv3-d16 is coming after -mfpu=neon I'd actually argue that the order is fine as it is -- giving the user-provided CFLAGS priority over build system ones makes sense, particularly from packagers' perspectives. -- Arun
