Build failure on aarch64

[cbix]

I'm currently packaging this for Arch Linux and ran into a compiler error on ARM64 (aarch64):

[  7%] Building CXX object /tmp/build/uhhyou-plugins/src/VSTPlugins-UhhyouPlugins0.48.0/build/CubicPadSynth/CMakeFiles/CubicPadSynth_dspcore_avx.dir/source/dsp/dspcore.cpp.o

c++: error: unrecognized command-line option ‘-mavx’

I believe the cmake file should only add the -mavx flag for x86_64 architectures.

Keep up the great work 🎉

[ryukau]

Hi, @cbix. Thanks for the report.

This issue is probably related to #17, that is following plugins are not available on aarch64 for now.

• CubicPadSynth
• EnvelopedSine
• EsPhaser
• IterativeSinCluster

I added switch DISABLE_X86_64_PLUGINS to disable the build of above plugins. Try following command, and please let me know if it still fails.

cmake \
  -DDISABLE_X86_64_PLUGINS=TRUE \
  -DCMAKE_BUILD_TYPE=Release \
  -DSMTG_MYPLUGINS_SRC_PATH="../../VSTPlugins" \
  -DSMTG_ADD_VST3_HOSTING_SAMPLES=FALSE \
  -DSMTG_ADD_VST3_PLUGINS_SAMPLES=FALSE \
  ..

cmake --build . -j

It's also possible to comment out affected plugins from top level CMakeLists.txt.

I guess this is good time to start rewriting those plugins without x86_64 SIMD. So please keep opening this issue. I'll close when the rewrite is finished, and they are confirmed working.

[cbix]

Thanks for this! Compilation mostly runs through now but the linker step fails:

/usr/sbin/ld: /build/VSTPlugins/lib/fftw3/linux/libfftw3f.a(apiplan.o): Relocations in generic ELF (EM: 62)
/usr/sbin/ld: /build/VSTPlugins/lib/fftw3/linux/libfftw3f.a(apiplan.o): Relocations in generic ELF (EM: 62)
/usr/sbin/ld: /build/VSTPlugins/lib/fftw3/linux/libfftw3f.a: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make[2]: *** [/build/VSTPlugins/build/MiniCliffEQ/CMakeFiles/MiniCliffEQ.dir/build.make:218: /build/build/VST3/Release/MiniCliffEQ.vst3/Contents/aarch64-linux/MiniCliffEQ.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:1779: /build/VSTPlugins/build/MiniCliffEQ/CMakeFiles/MiniCliffEQ.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Regarding SIMD, have you considered using simde for NEON/ARM compatibilty? We once managed to get VCV Rack to compile for ARM within an hour or so just by renaming some includes ;) One benefit of that is that you don't need separate build flags for different architectures, making compilation and packaging much simpler.

Anyway, if you need help adding or testing ARM support I can look into that.

[ryukau]

Ah, I was forgetting about FFTW3. The link error indicates that FFTW3 is missing on aarch64.

This repository contains static library of FFTW3 (lib/fftw3/linux/libfftw3f.a for Linux). The problem is that this libfftw3f.a was built on x86_64 environemnt, so it won't work on aarch64.

I made add_fftw3_to_aarch64 branch to solve this link error (link to relevant part).

I need your help to build FFTW3 for aarch64. See following for how to build FFTW3.

Building libfftw3f.a

For now, please build from fftw-3.3.8.tar.gz in following repository, or official distribution.

• ryukau/fftw3build
• FFTW3 Official ftp site

Latest FFTW3 version is 3.3.10, and it might be incompatible to the version 3.3.8 header used in this repository (lib/fftw3/fftw3.h).

To build, following commands might work. Change $installDir to some temporary directory.

tar -xf fftw-3.3.8.tar.gz
cd fftw-3.3.8

mkdir build
cd build

../configure --with-pic=yes --enable-single --prefix="$installDir"

make -j
make install

$installDir/.libs/libfftw3f.a is the static library file we need.

After that:

1. Move to this repository.
2. Checkout to add_fftw3_to_aarch64 branch.
3. Place libfftw3f.a into VSTPlugins/lib/fftw3/linux/aarch64.

Then try building this repository.

[ryukau]

On SIMD issue, I opened issue #22. I'll first go with plan A that seems the easiest.

[cbix]

@ryukau for Linux, I'd rather suggest to simply link fftw dynamically, since all major distributions should have the package already in their repo, including an aarch64 version. Then list that package as a dependency in the docs and add a cmake check to look for it.

I know it's not typical on Win and Mac to dynamically link 3rd party libs but it's quite common on Linux as long as the library is available in most package repos. Let me know if you need any help here!

Aaand if you still want to vendor a prebuilt static fftw3, it's included in the ubuntu package which you can download here.

[ryukau]

Thanks for the information!

I got libfftw3f.a from a Ubuntu package (link below), and added it to add_fftw3_to_aarch64 branch. Please let me know if it works or not.

• https://ubuntu.pkgs.org/22.04/ubuntu-main-arm64/libfftw3-dev_3.3.8-2ubuntu8_arm64.deb.html

---

I won't do dynamic linking on this repository. See the issue linked below.

• Thread Safe Planner · Issue #16 · FFTW/fftw3 · GitHub

I don't have complete understanding on the topic, but I'd like to avoid dynamic linking when it comes to audio plugins. I simply don't know what a library does or does not guarantee, and how a host handles the plugins. It's a kind of better safe than sorry situation.

I used to get some emails that says my plugins didn't work on their environment (mostly from old Intel mac users). It feels like my plugins have some bugs that relate to this kind of issue, but I'm not sure.

---

Edited on 2022-12-07 to fix link.

[cbix]

• https://ubuntu.pkgs.org/22.04/ubuntu-main-amd64/libfftw3-dev_3.3.8-2ubuntu8_amd64.deb.html

This is the link to the amd64/x86_64 package ;) but I noticed you added the correct library file to that branch and it's all building and running now (tested in Ardour on a RasPi 400) 🎉

Ideally we wouldn't need the DISABLE_X86_64_PLUGINS flag but rather have cmake decide that based on the target architecture, but that's ok for now and if I got you right, it's just a temporary solution anyway so we can test ARM builds for you.

[ryukau]

Thanks for pointing out. I fixed the link.

I merged add_fftw3_to_aarch64 branch into master.

Yes, DISABLE_X86_64_PLUGINS is a temporary one. It will be removed after issue #22 is solved.

[ryukau]

@cbix aarch64 port of the 4 plugins mensioned above is now available on add_sse2neon. Could you test them?

Note that add_sse2neon only builds the affected 4 plugins.

[cbix]

@ryukau is CubicPadSynth one of these 4?

[ 90%] Building CXX object /root/build/VSTPlugins/build/CubicPadSynth/CMakeFiles/CubicPadSynth.dir/source/dsp/dspcore.cpp.o
In file included from /root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/vectorclass.h:38,
                 from /root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl.hpp:28,
                 from /root/build/VSTPlugins/CubicPadSynth/source/dsp/dspcore.hpp:22,
                 from /root/build/VSTPlugins/CubicPadSynth/source/dsp/dspcore.cpp:18:
/root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/instrset.h:109:10: fatal error: x86intrin.h: No such file or directory
  109 | #include <x86intrin.h>                 // Gcc or Clang compiler
      |          ^~~~~~~~~~~~~
compilation terminated.

[ryukau]

Yes, they are the plugins on my first comment in this issue.

I updated add_sse2neon branch (8ae2d0f). How about this time?

[cbix]

@ryukau sorry for being a bit slow to respond, but I believe we're in different time zones :D I didn't try but maybe vst3sdk also works with a cross compiler? 🤔

Anyway, getting this error now:

[ 90%] Building CXX object /root/build/VSTPlugins/build/CubicPadSynth/CMakeFiles/CubicPadSynth.dir/source/dsp/dspcore.cpp.o
In file included from /root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/vectorclass.h:45,
                 from /root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl.hpp:28,
                 from /root/build/VSTPlugins/CubicPadSynth/source/dsp/dspcore.hpp:22,
                 from /root/build/VSTPlugins/CubicPadSynth/source/dsp/dspcore.cpp:18:
/root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/vectori128.h: In member function ‘Vec16c& Vec16c::cutoff(int)’:
/root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/vectori128.h:1008:33: error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ [-Wnarrowing]
 1008 |         const char mask[32] = { -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
      |                                 ^~
/root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/vectori128.h:1008:36: error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ [-Wnarrowing]
 1008 |         const char mask[32] = { -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
      |                                    ^~
/root/build/VSTPlugins/CubicPadSynth/source/dsp/../../../lib/vcl/vectori128.h:1008:39: error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ [-Wnarrowing]
 1008 |         const char mask[32] = { -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
      |                                       ^~
[...]

[ryukau]

Okay, it seems like sse2neon hack is not working on Linux aarch64. I also tried to use simde with vector class library (VCL), but couldn't figure out a way. So the remaining option is full rewrite of DSP with simde. It will take time.

Other concern I have is perfomance. The reason I'm using VCL is that the code I wrote with immintrin.h was far slower than the one I wrote with VCL. It was even slower than raw C++. Honestly, I'm inexperienced in this kind of low layer programming, so in worst case that my rewrite doesn't perform well, I'll halt the effort to port by myself. I'm not saying that it's doomed to fail, but trying to communicate that there are some uncertainty.

I'll look into cross compilation setup on WSL.

[ryukau]

@cbix I updated add_sse2neon branch. Could you test it again?

This time, I checked that the plugins can be built on cross compile environment (debootstrap on Debian sid). At least they didn't crash on VST 3 validator.

I was expecting more warning on VCL, but it turned out that -Wnarrowing reported on your last comment was the only remaining error.

[cbix]

@ryukau build now passes, good job 🎉 I can test running the plugins later today but so far it looks good!

[ryukau]

add_sse2neon is now merged into develop.

@cbix Just in case, did you confirm that the plugins on former add_sse2neon branch was working on Linux aarch64, on real hardware? I wasn't sure if you tested on x86_64 or aarch64.

[cbix]

@ryukau finally got to testing, and the 4 plugins are all working now! As soon as you do a new release we can push the plugins for aarch64 to our archlinux-proaudio repo.

[ryukau]

@cbix aarch64 codes are now available on master branch, and tagged as UhhyouPlugins0.50.0. Also, many thanks for testing!