Bug 678074 – media-libs/libwebp USE=neon - .../work/libwebp-1.0.2/src/dsp/cost_neon.c: In function ‘SetResidualCoeffs_NEON’: /usr/lib/include/arm_neon.h:11033:1: error: inlining failed in call to always_inline ‘vst1_lane_s32’: target specific option mismatch

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description tt_1 2019-02-15 14:50:35 UTC]

Created attachment 565456 [details]
emerge output

the full build log is attached

[Comment 1 tt_1 2019-02-15 14:51:30 UTC]

Created attachment 565458 [details]
output of emerge --info

[Comment 2 tt_1 2019-02-15 14:54:07 UTC]

This seems to be terribly broken, so please mask the neon useflag on arm profiles for the moment. You might want to ask arm64 team if they have the same problem.

[Comment 3 tt_1 2019-03-02 17:47:03 UTC]

friendly ping to mask the useflag, please.

[Comment 4 Nuno 2019-03-24 17:43:45 UTC]

Created attachment 570654 [details]
media-libs/libwebp-0.5.2 build.log

media-libs/libwebp-0.5.2 is also affected, even though the error message is not the same. Compiling with USE=-neon works.

[Comment 5 tt_1 2019-05-03 04:45:39 UTC]

@mozilla - the main consumer of libwebp is firefox, do you think you could take this bug over and just mask the neon useflag for all arm profiles? It's horribly broken, and it may not be fixed in the near future if at all. Thank you.

[Comment 6 Mike Gilbert 2019-06-14 17:26:41 UTC]

Your CFLAGS contain "-mfpu=vfpv3-d16", which overrides the "-mfpu=neon" that the builds system passes.

Does this package build if you remove that option from CFLAGS?

[Comment 7 tt_1 2019-06-14 17:42:57 UTC]

good catch, but that won't work either: 

>>> Configuring source in /var/tmp/portage/media-libs/libwebp-1.0.2/work/libwebp-1.0.2 ...
 * .arm: running multilib-minimal_abi_src_configure
 * econf: updating libwebp-1.0.2/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating libwebp-1.0.2/config.sub with /usr/share/gnuconfig/config.sub
/var/tmp/portage/media-libs/libwebp-1.0.2/work/libwebp-1.0.2/configure --prefix=/usr --build=armv7a-unknown-linux-gnueabihf --host=armv7a-unknown-linux-gnueabihf --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libwebp-1.0.2 --htmldir=/usr/share/doc/libwebp-1.0.2/html --with-sysroot=/ --libdir=/usr/lib --enable-libwebpmux --enable-libwebpdemux --enable-libwebpdecoder --disable-static --disable-swap-16bit-csp --enable-jpeg --enable-png --disable-gl --disable-tiff --disable-sse2 --disable-sse4.1 --enable-neon --disable-gif
checking build system type... armv7a-unknown-linux-gnueabihf
checking host system type... armv7a-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports the include directive... yes (GNU style)
checking for armv7a-unknown-linux-gnueabihf-gcc... armv7a-unknown-linux-gnueabihf-gcc
checking whether the C compiler works... no
configure: error: in `/var/tmp/portage/media-libs/libwebp-1.0.2/work/libwebp-1.0.2-.arm':
configure: error: C compiler cannot create executables
See `config.log' for more details

[Comment 8 tt_1 2019-06-14 17:44:28 UTC]

Created attachment 579794 [details]
config.log

[Comment 9 tt_1 2019-06-14 17:48:58 UTC]

I honestly don't have much hope that this is ever going to be fixed in the near future. The benefits of it are low, the amount of work is much higher and upstream want's to see a google account with a hardwired mobilephone number for every user that seeks to communicate with them/wants to hands in bugs. 

please simply mask the neon useflag for arm if you're able to, it helps users not to waste their time with this. thanks

[Comment 10 Mike Gilbert 2019-06-15 05:55:09 UTC]

Your config.log contains this:

CFLAGS='-O2 -pipe -march=armv7-a -mfpu=neon -mfloat-abi=hard #vfpv3-d16 -mfloat-abi=hard'

I suspect you tried to comment out part of your CFLAGS, and got the syntax wrong.

Based on the evidence presented so far, I am closing this bug.

[Comment 11 tt_1 2019-06-15 06:11:37 UTC]

yeah, it's been late in the night, I forgot to close the line. 

these cflags in make.conf are working in combination with USE="neon" 

CFLAGS="-O2 -pipe -march=armv7-a -mfpu=neon -mfloat-abi=hard"

so, it might be possible to use a bit of sed kungfu here to amend the cflags?

[Comment 12 Mike Gilbert 2019-06-15 06:44:50 UTC]

I don't really see any point. If you want to enable neon, you should use CFLAGS that support it.

[Comment 13 tt_1 2019-06-15 06:55:35 UTC]

I see your point, but mind you that it's perfectly normal to have -mfpu=vfpv3-d16 in CFLAGS from make.conf, and to use neon optimizations for a few packages on top of that. libpng, x265, firefox and vlc are examples for this. Are these working by accident? Why does libwebp have the useflag if the user has to manually intervene?

[Comment 14 Mike Gilbert 2019-06-16 01:59:05 UTC]

The neon USE flag controls the --enable-neon configure switch. This mainly controls whether certain source file get compiled or not.

This bug really caused by a limitation in the automake build system: to work properly, "-mfpu=neon" needs to be added to the compiler command after your CFLAGS, but automake offers no straightforward way to do this.

Adding -mfpu=neon to CFLAGS in the ebuild would probably work, but it is technically incorect; for the runtime CPU feature-detection code to work properly, only specific source files should be build built with this flag.

Possibly the ebuild could remove any -mfpu flag from CFLAGS, but that might cause other problems.

I think the only good solution would be for the libwebp developers to move to a build system that gives them more flexibility in which flags get passed to the compiler.

[Comment 15 Mike Gilbert 2019-06-17 17:48:46 UTC]

There's a rationale for the automake behavior here.

https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html

Long story short, the GNU automake developers believe the user should have the final say in what flags get passed to the compiler, even if that means they are allowed to shoot themselves in the foot.

[Comment 16 tt_1 2019-12-16 08:34:25 UTC]

this smells funny. I'm able to cross-compile libwebp-1.0.3 with USE="jpeg png tiff " CPU_FLAGS_ARM="neon", but can't compile it nativly. 

reopening to investigate.

[Comment 17 Nikolay Kichukov 2020-04-05 21:24:06 UTC]

I also had some incorrect arm flags in the CFLAGS variable:
'-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard'
changing those to:

'-O2 -pipe -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -march=armv8-a+crc+simd'

resolved the issue for me and the package compiled fine.

Thanks for the pointers Mike Gilbert!
This is not a bug.

[Comment 18 Mike Gilbert 2020-04-05 21:58:59 UTC]

Do not reopen this unless you have new information please.