Compiling on arm+nosimd

[dreadbit]

Hello, I'm trying to compile on armv7hf with +nosimd. Target is Toshiba AC100 (and the same thing as I understand with TrimSlice) Tegra2 SOC, my host system is BananaPI, both are runnig Bonnix. As I could understand, libwebp requires NEON at armv7. Am I right? Can I drop webp saying in .mozconfig ? Are there any other places where NEON cannot be avoided?

The actual error message is https://pastebin.com/dp61hLhT

That is how I am trying to compile that

export PATH=/opt/autoconf213/bin:$PATH
export CFLAGS=""
export AUTOCONF=/opt/autoconf213/bin/autoconf
export CFLAGS="-mfloat-abi=hard -march=armv7-a+nosimd"

export MOZ_MAKE_FLAGS="-j3"

rm .mozconfig
echo ac_add_options --disable-gstreamer >> .mozconfig

gcc -v:

Reading specs from /usr/lib/gcc/armv7hl-slackware-linux-gnueabi/13.1.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7hl-slackware-linux-gnueabi/13.1.0/lto-wrapper
Target: armv7hl-slackware-linux-gnueabi
Configured with: ../configure --prefix=/usr --libdir=/usr/lib --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,d,go,c,c++,fortran,lto,m2,objc,obj-c++ --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit --disable-libssp --enable-gnu-unique-object --enable-plugin --enable-lto --disable-install-libiberty --disable-werror --with-gnu-ld --with-isl --verbose --with-arch-directory=armv7hl --disable-gtktest --enable-clocale=gnu --with-tune=cortex-a8 --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --target=armv7hl-slackware-linux-gnueabi --build=armv7hl-slackware-linux-gnueabi --host=armv7hl-slackware-linux-gnueabi
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC) 

[rmottola]

I do compile on RaspberryPI, but it has SIMD.

you can disable WebRTC as a test and if you don't need it with --disable-webrtc I don't think you need do disable gstreamer anymore? I don't know about webp, never disabled it but it should be able to, otherwise I can check.

[dreadbit]

Will try and report. Compilation on PIs takes some time.

[dreadbit]

I confirm:

• just with --disable-webrtc it compiles on (simd) armv7 ok and runs on nosimd armv7 without any problem.
• If I force export CFLAGS=" -march=armv7-a+nosimd" it complains in configure that "we do not need any flags " for this architecture (or alike), if I shut it up, it compiles/work as well

My build is gopher://gopher.xepb.org/1/%7edtz/armv7hf/ArcticFox/

(the only) user of Toshiba AC100/PAZ00 on Bonslack is happy!

[rmottola]

Very good. So essentially, without WebRTC fine. Why do you need to foce CFLAGS then? On Intel and PPC I can set arch CFLAGS, so it must be something ARM specific, interesting to know.

Are you testing master or dev branch?

PS: at the beginning on Raspberry I had to fight a bit with neon... but I upgraded configure scripts with several FF patches. Will check.

[dreadbit]

Well, as I said I have armv7hl (Low Endian, Hard Float = (FPU with neon)) distribution -- and as I understood, "hf" implies neon by default. But my target is armv7hl (even with some FPU) without neon==simd. I've tried to avoid using neon code by default, specifying target. But for now, hopefully, the current options for armv7hl does not generate any neon code. However, I'll like to get some ensurance that that will not happen in future.

Strange that you had to fight with neon on RPis. RPi1 has armv6 without neon (and no neon or v6 at all?), RPi2 (and Oranges with H3) has v7+neon, and RPi3 an later are 64bit.

I'm not an expert in arm, I just own Toshiba AC100/PAZ00 and I like it.

I'm playing with 43 release.

Also, building for ppc and ppc64 targets on the same OS is in my plans. Also, I have HPPAs and Sparcs, so when I install the named OS there I may try there. One day ;-)

[rmottola]

@dreadbit any news here? Did you try to compile current git master, perhaps? RPI3 works fine for me.

[dreadbit]

I compiled 43.0 on every platform I have currently up with Slackware/Bonslack (ppc[32/64], x86[32/64],arm[v7nosimd+aarch]). Had some problems while ./mach package on ppc64, but still do not understand what to report (maybe my setup problem)

I've seen you released 43.1 and there are no major changes, so if you want me to try git version on armv7/nosimd, that's will be my next try

[dreadbit]

Good news: git version ate my -march=armv7-a+nosimd without complain Strange news: nor ./mach package not ./mach install works, the first error

0:13.92 gmake: Entering directory '/home/xxx/compile/Arcticfox/Arctic-Fox/obj-armv7l-unknown-linux-gnueabihf' 0:13.92 gmake[1]: Entering directory '/home/xx/compile/Arcticfox/Arctic-Fox/obj-armv7l-unknown-linux-gnueabihf/browser/installer' 0:13.94 Error: /home/xx/compile/Arcticfox/Arctic-Fox/browser/installer/package-manifest.in:45: Missing file(s): bin/browser/chrome/en-US

[rmottola]

@dreadbit these errors look un related to the arm architecture, strange. Any special config you are using? does about the same config work on x86 or ppc? locale files are not arch dependent...

[rmottola]

Please test v44 or current master, after all build system updates @dreadbit

[dreadbit]

Please test v44 or current master, after all build system updates @dreadbit Gone to heat up my CPUs for a bit.

[dreadbit]

[code] 2:59.22 cubeb_panner.o 2:59.22 In file included from /home/dtz/compile/Arcticfox/Arctic-Fox-44.0/media/libwebp/src/dsp/neon.h:15, 2:59.22 from /home/dtz/compile/Arcticfox/Arctic-Fox-44.0/media/libwebp/src/dsp/alpha_processing_neon.c:18: 2:59.24 /usr/lib/gcc/armv7hl-slackware-linux-gnueabi/13.2.0/include/arm_neon.h: In function 'ApplyAlphaMultiply_NEON': 2:59.25 /usr/lib/gcc/armv7hl-slackware-linux-gnueabi/13.2.0/include/arm_neon.h:6799:1: error: inlining failed in call to 'always_inline' 'vdupq_n_u16': target specific option mismatch 2:59.25 6799 | vdupq_n_u16 (uint16_t a) 2:59.25 | ^~~ 2:59.27 /home/dtz/compile/Arcticfox/Arctic-Fox-44.0/media/libwebp/src/dsp/alpha_processing_neon.c:44:27: note: called from here 2:59.27 44 | const uint16x8_t kOne = vdupq_n_u16(1u); 2:59.29 | ^~~~~~~ 2:59.29 /usr/lib/gcc/armv7hl-slackware-linux-gnueabi/13.2.0/include/arm_neon.h:13501:1: error: inlining failed in call to 'always_inline' 'vst4_u8': target specific option mismatch 2:59.29 13501 | vst4_u8 (uint8_t * a, uint8x8x4_t __b) 2:59.30 | ^~~ 2:59.30 /home/dtz/compile/Arcticfox/Arctic-Fox-44.0/media/libwebp/src/dsp/alpha_processing_neon.c:53:9: note: called from here 2:59.30 53 | vst4_u8((uint8_t*)(rgbx + i), RGBX); 2:59.32 | ^~~~~~~~~~~ 2:59.32 /usr/lib/gcc/armv7hl-slackware-linux-gnueabi/13.2.0/include/arm_neon.h:4699:1: error: inlining failed in call to 'always_inline' 'vshrn_n_u16': target specific option mismatch [/code]

export CFLAGS="-mfloat-abi=hard -march=armv7-a+nosimd" before ./mach build

[rmottola]

The issue seems to be specific to webp. Does "--disable-webp" work ? It is a backport done by PaleMoon, FF esr52 and esr60 didn't have webp, it comes up only in esr68.

media/libwebp/src/dsp/moz.build

Correctly seems to handle NEON:

media/libwebp/src/dsp/moz.build

The checks are defined in build/autoconf/arch.m4

Could you have a look how things get detected on your side? A very crude way would be to grep for HAVE_ARM_NEON and check the logs. A first guess would be it is detected as available.

[dreadbit]

Noooope at all!

1:28.59 checking for posix_fallocate... (cached) yes 1:28.60 creating ./config.data 1:28.60 1:28.61 1:28.61 1:28.62 Traceback (most recent call last): 1:28.62 File "/home/dtz/compile/Arcticfox/Arctic-Fox-44.0/configure.py", line 78, in 1:28.62 sys.exit(main(sys.argv)) 1:28.63 File "/home/dtz/compile/Arcticfox/Arctic-Fox-44.0/configure.py", line 22, in main 1:28.63 sandbox.run(os.path.join(os.path.dirname(file), 'moz.configure')) 1:28.63 File "/home/dtz/compile/Arcticfox/Arctic-Fox-44.0/python/mozbuild/mozbuild/configure/init.py", line 190, in run 1:28.64 raise InvalidOptionError('Unknown option: %s' % without_value) 1:28.64 mozbuild.configure.options.InvalidOptionError: Unknown option: --disable-webp 1:28.64 Fix above errors and then restart with\ 1:28.65 "/usr/bin/gmake -f client.mk build" 1:28.65 gmake[2]: [/home/dtz/compile/Arcticfox/Arctic-Fox-44.0/client.mk:364: configure] Error 1 1:28.65 gmake[1]: [/home/dtz/compile/Arcticfox/Arctic-Fox-44.0/client.mk:376: /home/dtz/compile/Arcticfox/Arctic-Fox-44.0/obj-armv7l-unknown-linux-gnueabihf/config.status] Error 2 1:28.66 gmake: [client.mk:171: build] Error 2 1:28.72 1630 compiler warnings present. 1:30.36 Failed to parse ccache stats output: Local storage:

[rmottola]

Ok, so no disable-webp... Maybe it can be added... But please check your arm detection and HAVE_ARM_NEON

[dreadbit]

Hi. Currently I'm in a weird place in PPC64 (44.0). Not sure I have to open the ticket but here is what I get with gcc (GCC) 13.2.0:

1:23.24 WebIDL.WebIDLError: error: Unresolved type '::MediaKeys'., /home/dtz/compile/ArcticFox/Arctic-Fox-44.0/obj-powerpc64-unknown-linux-gnu/dom/bindings/HTMLMediaElement.webidl line 159:21

UPD: Exactly same on x86_64.

[rmottola]

I don't know, I am able to compile with linux gcc13 amd64. It is my main platform. Would you try out current dev branch? lots of compiler and build system changes.

[dreadbit]

Reproduced x86_64 build of -dev on Slackware. Trying all the other architectures.

[rmottola]

Reproduced x86_64 build of -dev on Slackware. Trying all the other architectures.

interesting. I compiled on Linux amd64 & x86 without issues as well as MacOS 10.7, 10.9, 10.11... I'm committing some stuff to Media stuff these days. Let me know.

[rmottola]

Reproduced x86_64 build of -dev on Slackware. Trying all the other architectures.

do you explicitely disable eme? please try adding:

ac_add_options --disable-eme

in your mozconfig and report back.

[dreadbit]

ac_add_options --disable-eme

Yes is was there (even I do know know what it is, but it was in some .mozconfig example I've based on

[rmottola]

ac_add_options --disable-eme

Yes is was there (even I do know know what it is, but it was in some .mozconfig example I've based on

it is for playing encrypted video, but it needs a proprietary keys and code to be useful, so it was removed in PaleMoon. I think I cannot even package it if not being mozilla, never informed more.

[dreadbit]

Same version as tried at x86_64 -- compiled at ppc64 with no problems , cannot run with

[New Thread 0x3fffe6bfd100 (LWP 2106)]

Thread 14 "[pango] FcInit" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x3fffe6bfd100 (LWP 2106)] 0x00003ffff78f6d38 in .__memset_power4 () from /lib64/libc.so.6

I'm not able to think about that in nearest days