ObjC compile errors in Apple headers

Question

CrazyDef OP

Created Feb ’23

Replies 6

Boosts 0

Participants 2

Hi,

I'm trying to set up a quick demo app for part of our technology stack. (Basically implementing the same small app necessities for MacOS that we already have running on Linux and Windows.)

But I'm getting some errors in Apple headers that I don't how to solve.

From #import <Cocoa/Cocoa.h> I'm getting the following errors:

In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:13:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:14:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSAccessibility.h:12:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSAccessibilityConstants.h:130:15: error: unknown type name 'NSAttributedStringKey'; did you mean 'NSAttributedString'?
APPKIT_EXTERN NSAttributedStringKey const NSAccessibilityFontTextAttribute;                     //(NSDictionary<NSAccessibilityFontAttributeKey, id> *)
              ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:255:8: note: 'NSAttributedString' declared here
@class NSAttributedString;
       ^

Does anyone know what I'm doing wrong? Should I be declaring some preprocessor symbol or including some other header files before #import <Cocoa/Cocoa.h>?

I'm building from the command line with XCode Version 14.2 (14C18) on macOS Ventura 13.0 (22A8381).

Cheers, James

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’23

What file name extension are you using?

The Cocoa framework assumes Objective-C or Objective-C++, so .m or .mm. For example:

% cat main.m 
#include <Cocoa/Cocoa.h>

int main(int argc, char ** argv) {
    NSLog(@"Hello Cruel World!");
    return 0;
}
% clang main.m -framework Foundation
% ./a.out 
2023-02-28 10:43:03.670 a.out[19912:589298] Hello Cruel World!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

CrazyDef OP

Feb ’23

My header files are using .h, and my source files are using .mm.

0

Answer 3

DTS Engineer OP

Apple

Mar ’23

OK. So if you repeat my test from the previous post, does that fail in the same way?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

CrazyDef OP

Mar ’23

Yes it works fine.

And after a lot of digging, I've found the problem. I think. At least I've found a problem.

The file <Cocoa/Cocoa.h> includes <Foundation/Foundation.h>, which seems like a reasonable thing to do. However, clang is pulling one of our header files (which we include with "Foundation/Foundation.h") in instead of the Apple header. So it looks like I need to figure out the random way clang deals with user and system search paths (and the different ways it handles includes with <> and "") and try and figure out a solution.

Thanks for the help.

James

0

Answer 5

DTS Engineer OP

Apple

Mar ’23

However, clang is pulling one of our header files (which we include with "Foundation/Foundation.h") in instead of the Apple header.

Urgh!

This isn’t really my area of expertise but I do have one hint for: Check out the Quick Help for the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) build setting. That setting has been deprecated, and thus should be disabled, but, regardless, the Quick Help has some great info about how search paths work.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 6

CrazyDef OP

Mar ’23

Ah thanks, that documentation showed me the way to -iquote=<path> which, if I read the documentation correctly, suggests clang has a side list of include paths that it only uses for double-quoted include directives.

Now if only premake supported that...

Not that I care now. Once I figured out what the problem was, I realised it's probably easiest to just rename our file, which is what I've done. Life is too short to get bogged down with things like this. :)

0