[pulseaudio-discuss] [ANNOUNCE] PulseAudio 2.99.3 (3.0 RC3)

[Arun Raghavan]

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