The problem is that when you compile it as C++, the compiler mangles the name of the symbol NSApplicationMain, so it can't find it, since it's looking for something like __Z17NSApplicationMainiPPKc. You can use the nm program (from binutils) to see what symbols the object files are referencing:
$ # When compiled as Objective-C:
$ nm main.o | grep NSApplicationMain
U NSApplicationMain
$ # When compiled as Objective-C++:
$ nm main.o | grep NSApplicationMain
U _Z17NSApplicationMainiPPKc
In order to avoid this problem, C functions need to be declared with an extern "C" modifier in order to tell the compiler not to mangle the name. Looking into <AppKit/NSApplication.h>, the header file where NSApplicationMain is declared, I see this:
APPKIT_EXPORT int
NSApplicationMain(int argc, const char **argv);
Alas, APPKIT_EXPORT is defined to be one of extern, __declspec(dllexport), extern __declspec(dllexport), or nothing in <AppKit/AppKitDefines.h>. Since it's also used for global variable declarations, we can't get around this by redefining it to extern "C" (which would be extremely hacky and kludgy anyways). The AppKit header files do not seem to contain any extern "C" declarations at all, although I do see them in various header files under Foundation/ and GNUStepBase/.
So what can you do? The solution is to wrap your includes with an extern "C":
extern "C"
{
#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>
}
int main( int argc, const char ** argv ) {
return NSApplicationMain( argc, argv);
}
This will give the functions defined in those header files the proper linkage, and it will all work out. But you shouldn't have to do this -- I would file a bug report with GNUstep, telling them to add proper extern "C" declarations to their header files.
Best Answer
Try with gnustep-config