Error building standalone Mac application due to ambiguous Point and Component


#1

Hi,
as the title says, I get these “Reference to Point is ambiguous” and “Reference to Component is ambiguous” errors when building a standalone JUCE application with XCode 7.3.1 and a recent JUCE version (I updated JUCE to the development branch on July 8th).
It clearly has something to do with using the Accelerate framework in our internal processing (which has nothing to do with JUCE, but is included at some point obviously).
I read a few older posts on this topic, but I’m not sure how to handle this.
When I disable the use of Apple’s Accelerate framework (we have a macro in our code to fall back to our own math processing routines), then the application builds fine.
What is the cause of this (I would expect all JUCE code to be in a namespace thus avoiding conflicts), and how should I tackle this so that I can still use the Accelerate framework?
Thanks,
Koen


#2

Maybe try including Accelerate after including juce?


#3

I’m having the same issue. I’ve included the Juce header last in every file and I’m still getting the same errors.


#4

OK, thanks. I’ll try that.

I will need to juggle around with quite a lot of header files and include directives in .cpp files then, as it’s a complex project with many layers of code, but I guess there’s a way to find a path that I can put after the JUCE includes.

One thing I’ll need to look into is that the Projucer generates .cpp code files for components that have a header section where we can add our own headers ([Headers][/Headers]) and then after that, it includes the header for that component. My own includes are in the custom headers section of course, so they will always appear before the include that the Projucer generates.
But I can probably put the include that pulls in the Accelerate framework (indirectly through several other include files) in the next custom section called [MisUserDefs].
I’ll see how that goes an report back.


#5

Our solution is more of a workaround than a real fix, but maybe it helps. For us using the following code in JuceHeader.h prior to the includes or in the UserCodeSection of AppConfig.h solves the problem. The Accelerate Framework is still available and the application builds without errors.

#define Component CarbonDummyCompName // (workaround to avoid definition of "Component" by old Carbon headers)
#define Point CarbonDummyPointName // (workaround to avoid definition of "Point" by old Carbon headers)
#include <Accelerate/Accelerate.h>
#include <CoreServices/CoreServices.h>
#undef Component
#undef Point

I hope this helps
Roman


#6

Thanks for the help.
However, that didn’t work either for me… (undefined symbol CarbonDummyPointName, and I tried in various places, also moving the undefs a bit further down, etc …)

Here is a bit more info. Perhaps @Jules or @Timur also have some possible solutions. The strange thing is this all worked in earlier JUCE versions (I think 3.2.0 still worked, but not entirely sure).

We have a pure math processing file that doesn’t include any JUCE headers/code, and only contains one class.
Like so: template<typename T = float> class MyClass { ... }, with a MyClass.h (class definition) and MyClass.cpp file (with the method implementations).
As it is a template class, the MyClass.h pulls in the implementation via #include "MyClass.cpp" right after the class definition because it needs to be in the same compilation unit (it actually has template class specializations for types float and double).

This MyClass.h pulls in Accelerate with #include <Accelerate/Accelerate.h> right before the MyClass definition. So we have something like this:

#ifndef MYCOMPANY_MYCLASS_H
#define MYCOMPANY_MYCLASS_H

#include <Accelerate/Accelerate.h>

namespace MyCompnay
{
    template <typename T = float>
    class MyClass
    {
    public:
        ...
    private:
        ...
        
        FFTSetup m_FFTSetup;
        FFTSetupD m_FFTSetupD;
        
        DSPSplitComplex m_TempSplitData;
        DSPDoubleSplitComplex m_TempSplitDataD;
    };
}

#include "MyClass.cpp"

#endif    // #ifndef MYCOMPANY_MYCLASS_H

In other parts of our code (JUCE-related classes), we use this class, so it gets pulled in with #include "MyClass.h" (conditioned upon being on Mac/XCode of course), and we get the ambiguity problems mentioned above.

Now, what I did find out is the following:
If I put #define VIMAGE_H in our MyClass.h header file, right before the #include <Accelerate/Accelerate.h> line, everything builds fine without errors.
I assume Point and Component are defined somewhere in the <vImage/vImage.h> file that normally gets included, but that is avoided when you #define VIMAGE_H right before #include <Accelerate/Accelerate.h>.

I don’t consider this is real solution to the juce::Point / juce::Component conflicts.
But for me that seems to be the only (admittedly filthy) workaround I could find that works without conflicts with JUCE.

I also considered refactoring my class so that I don’t need to include the Accelerate.h header in my header (moving it to the implementation file), but since it’s a template class, the implementation still needs to be pulled in anyway, so I can’t shield it from the rest of my code as I would normally do.


#7

Putting this above the Accelerate include fixed this for me. Thanks!