Compiling dump1090 fails on arm

[skinkie]

cc -D_FORTIFY_SOURCE=2 -I. -DMODES_DUMP1090_VERSION=\"unknown\" -DMODES_DUMP1090_VARIANT=\"dump1090-fa\" -D_DEFAULT_SOURCE -DENABLE_CPUFEATURES -Icpu_features/include -DENABLE_RTLSDR -DENABLE_BLADERF -DSTARCH_MIX_ARM -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong -fno-plt -std=c11 -O3 -g -Wall -Wmissing-declarations -Werror -W -D_DEFAULT_SOURCE -fno-common -I/usr/include/ -I/usr/include/libusb-1.0 -I/usr/include/  -c -DSTARCH_MIX_ARM -march=armv7-a+neon-vfpv4 -mfpu=neon-vfpv4 -ffast-math dsp/generated/flavor.armv7a_neon_vfpv4.c -o dsp/generated/flavor.armv7a_neon_vfpv4.o
In file included from dsp/generated/flavor.armv7a_neon_vfpv4.c:18:
dsp/generated/../impl/magnitude_sc16.c: In function 'starch_magnitude_sc16_neon_vrsqrte_armv7a_neon_vfpv4':
dsp/generated/../impl/magnitude_sc16.c:52:5: error: converting a packed 'sc16_t' pointer (alignment 1) to a 'int16_t' {aka 'const short int'} pointer (alignment 2) may result in an unaligned pointer value [-Werror=address-of-packed-member]
   52 |     const int16_t * restrict in_align = (const int16_t *) STARCH_ALIGNED(in);
      |     ^~~~~
In file included from dsp/generated/flavor.armv7a_neon_vfpv4.c:19:
dsp/generated/../impl/magnitude_sc16q11.c: In function 'starch_magnitude_sc16q11_neon_vrsqrte_armv7a_neon_vfpv4':
dsp/generated/../impl/magnitude_sc16q11.c:89:5: error: converting a packed 'sc16_t' pointer (alignment 1) to a 'int16_t' {aka 'const short int'} pointer (alignment 2) may result in an unaligned pointer value [-Werror=address-of-packed-member]
   89 |     const int16_t * restrict in_align = (const int16_t *) STARCH_ALIGNED(in);
      |     ^~~~~
cc1: all warnings being treated as errors
make: *** [dsp/generated/makefile.arm:25: dsp/generated/flavor.armv7a_neon_vfpv4.o] Error 1
==> ERROR: A failure occurred in build().
    Aborting...

[mutability]

Should already be fixed on the dev branch, please try the dev branch,.

[hbokh]

Fails with a different error here, on both the master and dev branch.

Using dpkg-buildpackage -b --no-sign --build-profiles=custom,rtlsdr

cc: error: unrecognized argument in option ‘-march=armv7-a+neon-vfpv4’
cc: note: valid arguments to ‘-march=’ are: armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6kz armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc armv8.1-a armv8.1-a+crc iwmmxt iwmmxt2 native

This is on "Raspbian GNU/Linux 9 (stretch)" and RPi3 armv7l

$ cc --version
cc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516

This one however works:

$ cc -Wdate-time -D_FORTIFY_SOURCE=2 -I. -DMODES_DUMP1090_VERSION=\"5.1~dev\" -DMODES_DUMP1090_VARIANT=\"dump1090-fa\" -D_DEFAULT_SOURCE -DENABLE_CPUFEATURES -Icpu_features/include -DENABLE_RTLSDR -DSTARCH_MIX_ARM -g -O2 -fdebug-prefix-map=/home/pi/adsb-receiver/build/dump1090-fa/dump1090=. -fstack-protector-strong -Wformat -Werror=format-security -std=c11 -O3 -g -Wall -Wmissing-declarations -Werror -W -D_DEFAULT_SOURCE -fno-common -I/usr/include/ -c -DSTARCH_MIX_ARM -march=armv7-a -mfpu=neon-vfpv4 -ffast-math dsp/generated/flavor.armv7a_neon_vfpv4.c -o dsp/generated/flavor.armv7a_neon_vfpv4.o

replacing -march=armv7-a+neon-vfpv4 -mfpu=neon-vfpv4 with -march=armv7-a -mfpu=neon-vfpv4.

[mutability]

The NEON build isn't supported on stretch, please see debian-stretch/rules for an appropriate make invocation

(If you have a clean patch to support stretch with neon, that'd be great - please submit a PR - but otherwise I don't plan to add neon support to stretch since it's an old distribution version)

[hbokh]

Thanks Oliver.
This diff is taking me a step further (as in: a package with name dump1090-fa_5.1~dev_armhf.deb is build).

diff --git a/dsp/generated/makefile.arm b/dsp/generated/makefile.arm
index 58eaf5b..5145c5b 100644
--- a/dsp/generated/makefile.arm
+++ b/dsp/generated/makefile.arm
@@ -22,7 +22,7 @@ STARCH_CFLAGS := -DSTARCH_MIX_ARM


 dsp/generated/flavor.armv7a_neon_vfpv4.o: dsp/generated/flavor.armv7a_neon_vfpv4.c dsp/impl/mean_power_u16.c dsp/impl/magnitude_power_uc8.c dsp/impl/magnitude_uc8.c dsp/impl/magnitude_sc16q11.c dsp/impl/magnitude_sc16.c
-       $(STARCH_COMPILE) $(STARCH_CFLAGS) -march=armv7-a+neon-vfpv4 -mfpu=neon-vfpv4 -ffast-math dsp/generated/flavor.armv7a_neon_vfpv4.c -o dsp/generated/flavor.armv7a_neon_vfpv4.o
+       $(STARCH_COMPILE) $(STARCH_CFLAGS) -march=armv7-a -mfpu=neon-vfpv4 -ffast-math dsp/generated/flavor.armv7a_neon_vfpv4.c -o dsp/generated/flavor.armv7a_neon_vfpv4.o

 dsp/generated/flavor.generic.o: dsp/generated/flavor.generic.c dsp/impl/mean_power_u16.c dsp/impl/magnitude_power_uc8.c dsp/impl/magnitude_uc8.c dsp/impl/magnitude_sc16q11.c dsp/impl/magnitude_sc16.c
        $(STARCH_COMPILE) $(STARCH_CFLAGS)  dsp/generated/flavor.generic.c -o dsp/generated/flavor.generic.o

But judging your comment above, Stretch is considered EOL to compile fresh packages on, right?

[mutability]

Stretch is still supported and you should be able to build a stretch package without needing to patch everything if you use prepare-build.sh stretch

Oops, I see the README is out of date and doesn't mention this step! mea culpa. Run prepare-build.sh stretch and do the package build from the package-stretch subdir it creates.

[hbokh]

Ah, that's why I missed it! Compiling now as described above, in the master branch.
A new "issue":

$ dpkg-buildpackage -b --no-sign --build-profiles=custom,rtlsdr is showing BladeRF is included for some reason:

Building with:
  Version string:  5.0~bpo9+1
  DSP mix:         generic
  RTLSDR support:  yes
  BladeRF support: yes
  HackRF support:  no
  LimeSDR support: no

[mutability]

That'll be another case of the stretch support being limited - the custom build profile stuff only works with buster at the moment.

[apnof]

Should already be fixed on the dev branch, please try the dev branch,.

Can confirm for arm64 on a rock64 board.
5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Compiling master branch throws error from post 1, dev branch went through fine.

[johnsom]

I can also confirm the dev branch builds correctly on Pi4/focal.
I hope a 5.x release can be done soon to fix this.