Invalid use of incomplete type vSIMDType

[Orvillain]

@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.

[David Healey]

@Orvillain That line is the same in my fork and in Christoph's so I don't think that's the cause

[iamlamprey]

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

[David Healey]

@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?

[iamlamprey]

@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

[iamlamprey]

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 ambiguous errors so this all might just be xcode doing xcode things...

[David Healey]

@iamlamprey have you tried a diff between my fork and the develop branch?

[iamlamprey]

@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

[David Healey]

@iamlamprey it's just comparing the code in my fork which compiles to Christoph's code which doesn't compile and seeing what the difference is.

You can also compare between different commits within Christoph's repo.

We know the issue isn't in the JUCE modules because those haven't been touched.

[iamlamprey]

@David-Healey said in Invalid use of incomplete type vSIMDType:

We know the issue isn't in the JUCE modules because those haven't been touched.

The reference to Point is ambiguous error I'm getting is a confirmed JUCE issue (it was patched in a later version of JUCE), but it's caused by a clash with the Rubberband library so it's not HISE's fault. Either way I'm going to test the signalsmith shifter instead which sounds better out of the box anyway

I'm also getting a bunch of fftw errors when compiling your fork (development branch), I assume I need to install that on MacOS?

Edit: Yep signalsmith solved all of my woes