Raspberry Pi: No such file or directory 16 | #include <emmintrin.h> #18
Assignees
Comments
|
Thanks @madskjeldgaard – that's one of our dependencies (https://github.com/AlexHarker/HISSTools_Library), but I felt sure we'd spent some time with the author making it ARM friendlier a couple of years back. Will investigate. (And yes, that's a header for SIMD intrinsics: it may be that the That said, I do know that there's still some SIMD code in flucoma-core which definitely is still Intel-only. IIRC the plan is to retire that code in short order, but you'll find there's a couple of objects (perhaps the Transient ones?) that won't yet build on arm, even once we've sorted out the above. |
|
Yes, looking at the block in question Seems like it's not catching the right |
Thanks will give this a try (but also strange that these aren't picked up but maybe that's because arch Linux arm doesn't trigger those automatically) |
|
Will try it out. Thanks! |
so I've experimented with this now. I added the flags in the make part of the install process: (and I tried both flags even though it shouldn't make a difference). It got a bit further but then the linker freaked out with |
|
I tried adding |
and this didn't help either |
|
Surprised that didn't work. I thought we had fPIC enabled for GCC in any case, but evidently something isn't biting. If you add https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html |
and building with these commands |
|
Certainly all the plugins seem to have I might need to sleep on this (which actually means trawling SO for clues, but sounds better) |
|
Haha don't stress about it... I'll do the same. We'll figure it out !
Get Outlook for Android
|
|
Just tried it again making sure to clean up before install but still get the same errors about dangerous relocations and recompiling with -fPIC. A random idea: Could this be solved by compiling HISS tools statically ? |
|
I just remembered having the same issue with the daisysp library in this plugin suite |
|
The dependencies are being compiled statically, so I don't think that's it. I did a slightly more thorough check against the JSON, and the only things without PIC are files that aren't involved in the plugins (BaseAudioFile, IAudioFile etc., which support the import json
import re
import os
with open('/Users/owen/dev/flucoma-sc/archpicompile.json') as file:
d = json.load(file)
for c in d:
print(os.path.basename(c['file']))
m = re.search('-fPIC',c['command'])
if m is not None:
print('ok')
else:
print('no')
``` |
|
This SO post suggests that (sometimes?) GCC cares about where What happens if you also add |
Thanks I tried that but it didn't help. This is the commands I used: SC_SRC="/usr/share/supercollider-headers"
cd "$srcdir/$pkgname-$pkgver"
git submodule update --init --recursive
mkdir build; cd build
DEST="$pkgdir/usr/share/SuperCollider/Extensions"
FLUCOMA_CORE=$srcdir/flucoma-core
CXX_FLAGS="-fPIC"
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DFLUID_PATH=$FLUCOMA_CORE -DSC_PATH=$SC_SRC -DCMAKE_INSTALL_PREFIX=$DEST ..
make CXX_FLAGS="-D__arm__\ \-fPIC"This time I noticed something further up in the log: Could this be a clue? It seems like CMake is confused about simd stuff here at least. Here's the full output from the build: |
|
also tried this flavour of cmake just in case: |
|
WAIT |
|
.... Sorry for the cliffhanger. I am now getting A LITTLE BIT FURTHER. The good news: No more fpic complaints. The bad news: the simd stuff is back. These commands: git submodule update --init --recursive
mkdir build; cd build
DEST="$pkgdir/usr/share/SuperCollider/Extensions"
FLUCOMA_CORE=$srcdir/flucoma-core
cmake -E env CXXFLAGS="-D__arm64=1 -fPIC" cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DFLUID_PATH=$FLUCOMA_CORE -DSC_PATH=$SC_SRC -DCMAKE_INSTALL_PREFIX=$DEST ..
make
Get me as far as this (that is, past FluidAmpGate which caused trouble earlier with fpic): |
|
(Cmake is so unbelievably fuzzy and non-informative about command line arguments sometimes....) |
|
ah but |
|
Some of that vagueness might be our fault, although I agree it's hard to tell sometimes. Anyway, well done on getting the PIC stuff happy. The SIMD stuff I at least understand: I've already got an issue filed to update that header so that the intel specific includes are conditional. I'll nudge the author again. Meanwhile that means that some objects aren't going to build on arm yet, unfortunately. Is it possible for your script to delete folders from the source tree to disable these targets? I think the affected objects would be
|
Phew, at least we're now back in the territory of facts and have left the world of weird magic... I can try and see if that's possible. It should be doable! |
|
Okay, so I got it building now (but also had to remove FluidNMFMorph unfortunately). Here are the steps from my build script: build() {
SC_SRC="/usr/share/supercollider-headers"
cd "$srcdir/$pkgname-$pkgver"
git submodule update --init --recursive
# Remove plugins that are not compatible with arm architectures
ARM_EXCLUDE=("FluidSines" "FluidBufSines" "FluidAudioTransport" "FluidBufAudioTransport" "FluidNoveltySlice" "FluidBufNoveltySlice" "FluidTransients" "Flui
dBufTransients" "FluidTransientSlice" "FluidBufTransientSlice" "FluidNMFMorph")
for PLUG in "${ARM_EXCLUDE[@]}"; do rm -rfv "src/$PLUG"; done
mkdir build; cd build
DEST="$pkgdir/usr/share/SuperCollider/Extensions"
FLUCOMA_CORE=$srcdir/flucoma-core
cmake -E env CXXFLAGS="-D__arm64=1 -fPIC" cmake -DFLUID_PATH=$FLUCOMA_CORE -DSC_PATH=$SC_SRC -DCMAKE_INSTALL_PREFIX=$DEST ..
make
# cmake -DSC_PATH=<location of your SC source> -DFLUID_PATH=<location of Fluid Corpus Manipulation Library> ..
}I will update the package on the arch user repository to build like this if it detects an arm architecture |
|
Great stuff, well done and thanks for being patient. Was the NMFMorph issue also an SIMD one, or something else? I've put in a PR for the SIMD header change, but also it turns out that a lot of those objects don't actually need that header any longer, so you should be able to switch most of them back in shortly, once we've cleaned up the includes. |
Yep it was the same error it seems. Thanks for the help! |
|
It should now be possible to install it on arch arm / manjaro arm using |
Oh and that's great news. Just ping me here whenever there is progress but for now this works... |
|
This might be fixed now. I just bumped our HISSTools version, and I know Alex put some fixes in to better support ARM (and the troublesome header of ours is now gone). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi ! Just testing out compiling and installing this from master branch GitHub source on a Pi4 running arch Linux arm and I have run into a problem. It smells like an x86 exclusive dependency ? Thanks !! Keep up the nice work !
[ 8%] Building CXX object _deps/flucoma-core-build/CMakeFiles/HISSTools_FFT.dir//hisstools-src/HISSTools_FFT/HISSTools_FFT.cpp.o In file included from /home/alarm/.cache/yay/supercollider-flucoma-git/src/supercollider-flucoma-git-r1179.5956e97/build/_deps/hisstools-src/HISSTools_FFT/HISSTools_FFT.cpp:3: /home/alarm/.cache/yay/supercollider-flucoma-git/src/supercollider-flucoma-git-r1179.5956e97/build/_deps/hisstools-src/HISSTools_FFT/HISSTools_FFT_Core.h:16:10: fatal error: emmintrin.h: No such file or directory 16 | #include <emmintrin.h> | ^~~~~~~~~~~~~ compilation terminated. make[2]: *** [_deps/flucoma-core-build/CMakeFiles/HISSTools_FFT.dir/build.make:76: _deps/flucoma-core-build/CMakeFiles/HISSTools_FFT.dir//hisstools-src/HISSTools_FFT/HISSTools_FFT.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1071: _deps/flucoma-core-build/CMakeFiles/HISSTools_FFT.dir/all] Error 2 make: *** [Makefile:136: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...
The text was updated successfully, but these errors were encountered: