VST architecture "hf" for ARM

[jpcima]

sfztools/sfizz-ui#79
Detection the vst architecture by uname
Only if not cross-compiling, and only if not Intel (it can be messed with by flags -m32/-m64)

[x42]

Also when compiling natively on a Raspberry Pi this fails. -- Rapbian is a debian armhf system.

https://steinbergmedia.github.io/vst3_doc/vstinterfaces/vst3loc.html#linuxformat
specifies based on the RPM Terminology + "-linux"

RPM terminology for armhf is armv7hl

It'd probably be safest to extract this from gcc -dumpmachine or gcc --print-multiarch -- that also works when cross-compiling

[jpcima]

It'd probably be safest to extract this from gcc -dumpmachine or gcc --print-multiarch -- that also works when cross-compiling

It does not seem to provide useful results. On a generic arm gcc compiler, the result is of the form arm-* regardless of flags.

If uname also is incorrect, I don't have the slightest idea on how to resolve this.
I'll see about emulating Raspian and researching into this issue.

[falkTX]

JUCE has a way around this, by running a CLI tool that it itself builds, and getting the proper output filename from there
See juce-framework/JUCE@6f22faf

[x42]

I suppose that plugin-hosts on armhf/armv7hl can also load plugins that don't use the hardware floating point unit (ie. armv7l).
But since pretty much all DSP is floating point and most v7 microarchitectures have a FPU (incl. RPi 3,4 which are most popular) it likely makes no sense to distribute any armv7l binaries.

[jpcima]

But since pretty much all DSP is floating point and most v7 microarchitectures have a FPU (incl. RPi 3,4 which are most popular) it likely makes no sense to distribute any armv7l binaries.

Yes that's a fair assumption. Are you suggesting that, as we see some architecture armvN, we append hl at the end of it and that's it? if this would work, I'll be perfectly fine with this solution.

JUCE has a way around this, by running a CLI tool that it itself builds, and getting the proper output filename from there

I'm seeing armv7l listed, no armv7hl though.

[x42]

Well, that's the bug I had reported. The VST specification mandates "RPM Terminology". ARM v7 with hardware floating point support is called armv7hl in Red-Hat land.

Personally I'd prefer to argue that using arch-tripletts would be preferable to RPM terminology, but that's a different story.

[jpcima]

OK done, it's armv7hl from now.

[paulfd]

In this case you might also want to report a bug in Reaper, because it seems my version does not recognize armv7hl-linux in the vst3 content folder. At this point I would argue for pragmatism and add a symlink.

[paulfd]

(I will report the bug in Reaper, it was more rhetorical ;-))

[jpcima]

Looking at the VST3 host, official code
public.sdk/source/vst/hosting/module_linux.cpp

We have this to determine the architecture directory.
https://github.com/steinbergmedia/vst3_public_sdk/blob/a395ed998bfee1969d623c15a5825160de7fd32c/source/vst/hosting/module_linux.cpp#L61-L70

What's the value utsname.machine on ARM computers?

[x42]

Looking around it seems that many projects use armv7l :(

perhaps we should take this to https://github.com/steinbergmedia/vst3sdk/issues or https://github.com/steinbergmedia/vst3_pluginterfaces/pulls to clarify.