Invalid use of incomplete type vSIMDType
-
@Christoph-Hart Bump bump
-
just began my linux HISE journey and also getting this error on a clean install

-
@iamlamprey Yeah I'm not sure what's causing it because it works on my fork and I've merged all of Christoph's changes. I need to do a diff and see if I can find the source of the issue but I don't have time at the moment.
-
@d-healey Clanker found it for me:
HISE/hi_streaming/hi_streaming/MonolithAudioFormat.cppjuce::AudioFormatReader* HlacMonolithInfo::createUserInterfaceReader(int sampleIndex, int channelIndex, int64 realSampleLength) { if (isPositiveAndBelow(sampleIndex, sampleInfo.size())) { const auto& info = sampleInfo[sampleIndex]; const int64 start = info.start; // replace this (line 370): const int64 length = jmin<int64>(realSampleLength, info.length); // with this: const int64 length = std::min<int64>(realSampleLength, info.length); // or this: const int64 length = jmin((int64) realSampleLength, (int64) info.length); // rest of function } }@Christoph-Hart Simple fix above, not sure which version is better but the std::min one works for the latest Ubuntu LTS
-
-
@d-healey chatGPT lol
-
@iamlamprey said in Invalid use of incomplete type vSIMDType:
Clanker found it for me:
I think it's lying to you again. This is the line in my fork and it compiles without issue
-
@d-healey I'm not sure if it's lying necessarily, more likely there's multiple ways to skin a cat
Either way it worked on my end, tested on Ubuntu LTS and the latest Mint
-
@d-healey I think this is a Linux compiler thing. On Linux int64_t is defined as long int - whereas Windows and Mac it is defined as long long int.
The compiler is throwing a wobbly because of that.
I think.
-
@Orvillain said in Invalid use of incomplete type vSIMDType:
I think this is a Linux compiler thing.
Linux user here
-
@David-Healey said in Invalid use of incomplete type vSIMDType:
@Orvillain said in Invalid use of incomplete type vSIMDType:
I think this is a Linux compiler thing.
Linux user here
Yeah I know. You're getting the issue with the dev branch but not your fork right? Your error:
../../../../../hise/hi_streaming/../JUCE/modules/juce_dsp/containers/juce_SIMDRegister.h:85:11: error: invalid use of incomplete type ‘using juce::dsp::SIMDRegister<long long int>::NativeOps = struct juce::dsp::SIMDNativeOps<long long int>’ {aka ‘struct juce::dsp::SIMDNativeOps<long long int>’}That is telling you that SIMDRegister/SIMDNativeOps is being used incorrectly. The only thing I can think of is that it is being called with long long int, which is correct for Windows and Mac... but on Linux I think it should be called with long int - not long long int.
I'd check that line in your fork and dev branch and make sure it is the same, if you haven't already.
-
@Orvillain That line is in a JUCE module, we no touch those.
-
@David-Healey Well I don't know what else to tell you: https://forum.juce.com/t/int64-t-vs-juce-int64/45358
As reported here - it is a typedef issue, specifically affecting Linux compiles.
Actually, I might have that wrong. That thread is about juce:int_64.
-
@Orvillain That line is the same in my fork and in Christoph's so I don't think that's the cause
-
This SIMD stuff is quite the pest, getting similar errors on MacOS even after my "fix":
In file included from /Users/user/Documents/altar/DspNetworks/Binaries/Source/Main.cpp:6: In file included from /Users/user/Documents/HISE/hi_dsp_library/hi_dsp_library.h:55: In file included from /Users/user/Documents/HISE/hi_tools/hi_tools.h:148: In file included from /Users/user/Documents/HISE/hi_dsp_library/../hi_tools/../hi_streaming/hi_streaming.h:62: In file included from /Users/user/Documents/HISE/JUCE/modules/juce_dsp/juce_dsp.h:236: /Users/user/Documents/HISE/hi_dsp_library/../hi_tools/../hi_streaming/../JUCE/modules/juce_dsp/containers/juce_SIMDRegister.h:85:32: error: implicit instantiation of undefined template 'juce::dsp::SIMDNativeOps<unsigned long>' using vSIMDType = typename NativeOps::vSIMDType;And here's an old post from the man himself:
https://forum.juce.com/t/dsp-module-breaks-compilation-on-linux/27346/4
Seems like it's either a JUCE issue, or just the different behaviors of different compilers
-
@iamlamprey said in Invalid use of incomplete type vSIMDType:
Seems like it's either a JUCE issue, or just the different behaviors of different compilers
Which compiler are you using on MacOS? Does my fork work?
-
@David-Healey Whatever the default is, I think clang
I should clarify: this error is happening when I try and compile third-party nodes, HISE itself built just fine. i doubt I could use your fork since mine has Altar-specific changes to include the Rubberband library
-
Still working at this, found another juce thread:
https://forum.juce.com/t/dsp-module-no-longer-compiles-on-linux-after-april-17th-commit/27684/6

possibly related to the explicit template with jmin? there's a few of those in that monolith file
this clank also fixes that particular error:
// Include this AFTER juce_dsp.h // It aliases unsigned long to the existing uint64_t SIMDNativeOps specialization, // fixing builds on platforms where MaskType resolves to unsigned long. #pragma once #include "juce_dsp/juce_dsp.h" namespace juce { namespace dsp { template<> struct SIMDNativeOps<unsigned long> : SIMDNativeOps<std::uint64_t> {}; }}which forces it to use uint64_t, but I'm also getting a bunch of
Reference to Point is ambiguouserrors so this all might just be xcode doing xcode things... -
@iamlamprey have you tried a diff between my fork and the develop branch?
-
@David-Healey said in Invalid use of incomplete type vSIMDType:
@iamlamprey have you tried a diff between my fork and the develop branch?
not sure what that is or how to do it lol but I'll start googling