Unknown Type Name "NSString" on new Mac OS Build


#1

Just tried to build a project for Mac OS using XCode version 10.1 that has been working on MS Windows and I’m getting errors such as "Unknown type name ‘NSString’ NSObjRuntime.h.

I built using the most recent Projucer on Mac OS Mojave 10.14.3 and I suspect a header file isn’t being included by Projucer but I have no idea what that might be. Any suggestions would be greatly appreciated.


#2

?? Do you try to code in Objectiv-c with the projucer ?
In C++ you simply have String …


#3

Does your project include own modules? This sounds like an error I encountered lately when setting up a module but forgetting to put a .mm file into the modules root folder that simply includes the .cpp file. This leads to problems if you somehow include MacOS specific Obj-C headers in your module, as the Projucer only sees a .cpp file and tries to treat and compile it as a regular c++ source which won’t work when Obj-C headers are included. Compiling the source file as Obj-C++ (aka .mm) solves the problem, this is why Projucer chooses an .mm source over a .cpp source file with the same name in the same module root folder.


#4

I’m absolutely new using any Apple products but I’m trying to compile using C++ and not Objective C as shown in the Projucer screenshot below:

Screen Shot 2019-03-04 at 6.12.41 PM.png

The build settings in Xcode look like:

Screen Shot 2019-03-04 at 6.13.29 PM.png

Screen Shot 2019-03-04 at 6.14.04 PM.png.

If you see anything here that looks like I’m using Objective C, please let me know. This is a project developed on MS Windows using Visual Studio C++ so unless I’m mistaking, I can’t start compiling with Objective C now.


#5

Ok, so you don’t have to use NSString but String. NSObject are used in the obj-C language…


#6

PluginPenguin,

I don’t know what you mean by “own modules” but I don’t include any MacOS specific Obj-C headers in any of the files I’ve created. The JuceLibraryCode folder does contain *.mm files that include *.mm headers so is it possible JUCE is somehow including these even though I’m trying to compile with C++ and not Obj-C?


#7

what happens if you compile an example? from the juce library


#8

nseaprotector,

Thank you very much for responding but it’s not me that’s trying to use NSString. When I build in Xcode, these errors show up because Mac OS files such as NSObjCRuntime.h and NSZone.h are somehow being included in the build and they reference NSString:

Screen Shot 2019-03-04 at 6.50.30 PM.png

I’m wondering if XCode is trying to build for Obj-C when I’m trying to build with C++. I’ve included screenshots of my build settings in one of my previous replies.


#9

Ok, and have you got the same problem with different projects ?
If not, crash the exporter and create a new one.


#10

nseaprotector,

This is the only project that I have right now. The “Hello World” project build ok but that was before I added all my own C++ files.

I just built the JUCE DemoRunner and it built and ran OK. The Projucer settings for this demo includes many Extra Compiler Flags and some Custom Xcode Resource Folders that I don’t have in the Projucer for the failing project but I suspect that’s not the problem. The entry for C++ Language Standard (Default (C++14)) is the same as my project.


#11

ok, and did you try to recreate the Xcode exporter in the projucer ?


#12

I added the Extra Compiler Flags from the demo Projucer but that didn’t solve the problem.

The mystery to me is, why is the header file "NSObjCRuntime.h being included in the build? The Xcode error message is

Unknown type name ‘NSString’ NSObjCRuntime.h

and then it explains this by saying

“In file included from /Users//JUCE/modules/juce_audio_devices/juce_audio_devices.cpp:46”

The file included on line 46 of the .cpp file is"juce_audio_devices.h" but there is no reference to NSObjCRuntime.h in that header file.


#13

Are you familiar with how #include work? In your case:

  • JUCE/modules/juce_audio_devices/juce_audio_devices.cpp includes:
    • JUCE/modules/juce_audio_devices/juce_audio_devices.h, which includes:
      • JUCE/modules/juce_events/juce_events.h, which includes:
        • JUCE/modules/juce_core/juce_core.h, which includes:
          • JUCE/modules/juce_core/native/juce_BasicNativeHeaders.h, which includes:
            • <Cocoa/Cocoa.h>, which includes:
              • NSObjCRuntime.h

And this is exactly what Xcode is telling you.


#14

Ok, I think you misunderstood what I meant. Let me try to clarify this a bit.

I didn’t mean that you wrote any line of Obj-C code yourself. However, a lot of Apple APIs are written in Objective C. So JUCE as a cross-platform framework of course contains some Objective C code to implement the MacOS / iOS specific stuff. However JUCE only presents you a C++ interface.

Now how does this work? Beneath pure C++ sources (.cpp) and pure Objective C sources (.m) clang (the compiler used for Mac and iOS) also allows to compile Objective C++ sources (.mm). Objective C++ sources can contain Objective C code as well as C++ code or both. So all modules that come with JUCE usually contain a .mm file in its root directory beneath the .cpp file that do nothing more than just include the .cpp file (take a look here for an example: https://github.com/WeAreROLI/JUCE/blob/develop/modules/juce_audio_devices/juce_audio_devices.mm). Now if the Projucer sees a .mm file and a .cpp file in the module root folder, it decides to compile the .mm file as Objective C++ source and just ignore the C++ file. This allows JUCE to include Apples Objective C headers somewhere deep down in the framework when they are needed to talk to the OS.

This was just to explain what I meant.

Now regarding your actual problem, I wanted to point you to the fact that if you include some headers in your .cpp file that somewhere deep down the include path includes an Objective C header this might not work if your file is called .cpp as clang then tries to compile it as pure C++ source. Trying to do so leads to error messages exactly like the one you posted. You very likely won’t encounter this problem with a Windows build as this includes some other headers under the hood - this is just how the encapsulation of the OS specific stuff works. This could be solved by adding a .mm file that just includes the .cpp file. It will be ignored on non-apple systems.

However, if you encounter this problem with one of the JUCE demo projects the source of the problem might obviously not be your own code.

I hope this helped you to get a better idea of what I meant and gives you some hints to search for the solution to your problem.


#15

Just to clarify a bit on this, a common way to manage the codebase for your own projects is to organize your own code just the way the JUCE framework code is organized: The JUCE module format. You should take a look here: https://github.com/WeAreROLI/JUCE/blob/develop/modules/JUCE%20Module%20Format.txt

This might help you a lot to actually understand how JUCE works :slight_smile:

However if you never heard of modules before, you most likely didn’t write own modules and messed up with the module structure, so just take this as an information.


#16

Are you sure you added only your own files?

Based on the last Xcode screenshot you shared, your Xcode project is trying to compile MKEditor/JuceLibraryCode/include_juce_audio_devices.cpp, which is not correct for macOS. Instead it should be compiling MKEditor/JuceLibraryCode/include_juce_audio_devices.mm (the extension makes a big difference, as @PluginPenguin explained).

My guess is that you manually added MKEditor/JuceLibraryCode/include_juce_audio_devices.cpp to the sources of your project when porting it from Windows.


#17

McMartin,

Thank you for helping out.

I do understand how the nesting of #include files works and so I understand how NSObjRuntime.h eventually gets included. I just don’t know why it’s not compiling correctly unless the problem is that I need a .mm file that includes my .cpp file like PluginPenguin says. If that’s the case, I wonder how the JUCE DemoRunner compiles correctly because I don’t see any .mm files that include the .cpp files.

Regarding the manually adding of the include_juce_audio_devices.cpp file, I’m pretty sure I didn’t add this file to the project myself. Here’s a screenshot of my Projucer that shows it resides in the JuceLibraryCode folder so I’m assuming that’s why it gets compiled.

Screen Shot 2019-03-05 at 9.51.41 AM.png


#18

The Builds and JuceLibraryCode folders are created/updated by Projucer when you save your project. They should not be referenced in your project.


#19

PluginPenguin,

I did not set up my modules the way your link to the module format described. I left the file structure the same way I built for Windows. Are you saying that will not work and I need to set up the files as described in that link? It doesn’t look like the JUCE DemoRunner project was organized that way but it builds ok.


#20

McMartin,

Thank you.

I did not intentionally add the JuceLibraryCode files to the Projucer. I expect it had something to do with the way I’m still getting used to navigating around a MAC and selecting and copying files. Starting over with Projucer and only adding my own source files has solved the problem.

I also want to thank all the others that helped me out in getting to the bottom of this. Even though it turned out to be a simple error on my part, I’ve learned things from all the comments I’ve received.