[pulseaudio-discuss] [ANNOUNCE] PulseAudio 2.99.3 (3.0 RC3)
arun.raghavan at collabora.co.uk
Fri Dec 7 05:33:36 PST 2012
On Fri, 2012-12-07 at 14:20 +0100, Peter Meerwald wrote:
> > 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_LANG_PROGRAM(, ),
> 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
> 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
> 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.
More information about the pulseaudio-discuss