• 15
• 15
• 11
• 9
• 10

# Having loads of trouble compiling C++ SDL/OpenGL project on Mac OS X

This topic is 2170 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

We've been encountering many barriers in our attempts to compile our SDL/OpenGL game on Mac OS X. The main development OS is Windows but we've also had no problem building the game for Linux operating systems.

The preferred method of library distribution on OS X is through frameworks, and SDL is no different. Since SDL has several sub-libraries, each in a separate framework, the #include code is different between systems. (The OpenGL #include code is also different, for the record.)

#ifndef __APPLE__ #include <GL/gl.h> #include <SDL/SDL.h> #include <SDL/SDL_image.h> #include <SDL/SDL_mixer.h> #elseif #include <OpenGL/gl.h> #include <SDL/SDL.h> #include <SDL_image/SDL_image.h> #include <SDL_mixer/SDL_mixer.h> #endif

This is all fine and dandy but that actually gives me compilation errors in the frameworks' headers themselves, as they refer to files from other parts of SDL with the assumption they're in the same folder. One could edit the headers but other errors happen then. Since frameworks are the "proper" way of distributing libraries in your application bundles, I'm going to assume that there's just something wrong on my end and not that SDL frameworks are completely unusable by anyone.

In addition, a perturbing problem with OpenGL is that it insists that GLuint is not defined. This is baffling, considering you can go to OpenGL/gl.h yourself and plainly see the typedef of GLuint.

I've been struggling with these issues for a while and I'd appreciate it if someone would be able to help with this.

##### Share on other sites
SDL is not a system framework. You should use quotes instead of angle brackets to include SDL, SDL_image, and SDL_mixer.

SDL has a header file for OpenGL, SDL_opengl.h, that keeps you from having to worry about how to include the OpenGL headers on various operating systems. I suggest including SDL_opengl.h instead of gl.h.

You haven't said how you are trying to compile your code. Are you using Xcode or are you trying to compile using a makefile? If you are using a makefile, you need to link to the Cocoa framework because the Mac version of SDL uses Cocoa. You also need to add the file SDLMain.m to your Xcode project or makefile. SDLMain.m contains glue code that allows you to compile SDL code on Mac OS X.

If you click the link in my signature, you can find a tutorial I wrote on using SDL and OpenGL on Mac OS X. You can also find my blog, which has a category for SDL posts, that could help you.

To any moderator on this board, you may want to move this topic to the APIs and Tools board. The APIs and Tools board houses most SDL questions.

##### Share on other sites
SDL is not a system framework. You should use quotes instead of angle brackets to include SDL, SDL_image, and SDL_mixer.

SDL has a header file for OpenGL, SDL_opengl.h, that keeps you from having to worry about how to include the OpenGL headers on various operating systems. I suggest including SDL_opengl.h instead of gl.h.
Ah, thank you. Have adjusted my code with both of these in mind.

You haven't said how you are trying to compile your code. Are you using Xcode or are you trying to compile using a makefile? If you are using a makefile, you need to link to the Cocoa framework because the Mac version of SDL uses Cocoa. You also need to add the file SDLMain.m to your Xcode project or makefile. SDLMain.m contains glue code that allows you to compile SDL code on Mac OS X.
Sorry, I'm using Xcode. I am also using SDLMain.m and linking to the cocoa framework.

After making those changes to the code and reading your SDL and OpenGL on Mac OS X article, I'm still getting errors:

Parse Issue
Unknown type name 'GLuint'

Almost all the errors are like this, sometimes replacing GLuint with other things such as Mix_Chunk and SDL_Color... basically any defined data type.

Eventually I get a "Too many errors emitted, stopping now." message.

EDIT: On clean and rebuild I've discovered SDLMain is throwing up a ton of errors related to automatic reference counting mode. I'm going to assume I should be compiling with automatic reference counting OFF -- could someone confirm this for me?

##### Share on other sites

EDIT: On clean and rebuild I've discovered SDLMain is throwing up a ton of errors related to automatic reference counting mode. I'm going to assume I should be compiling with automatic reference counting OFF -- could someone confirm this for me?

You should not be using automatic reference counting. That is for Objective-C code.

You may have a search path problem, where Xcode can't find the SDL framework and/or headers. Start with adding the path to SDL to Xcode's Framework Search Paths build setting. If that doesn't work, add a path to the Header Search Paths build setting. If you're using Xcode 4, the following article may help you:

Using SDL with Xcode 4

##### Share on other sites
Turns out I was being incredibly dense and using #elseif instead of #else. Now it compiles.

However, now the program is crashing with an EXC_BAD_ACCESS signal at SDL_PollEvent(&event).
If I remove the event handling code, the game runs, though obviously without input.

Also, if I force it to skip the splash screen and start the level, it crashes with an EXC_BAD_ACCESS signal at the call to the encryption library I use to encrypt level and save data (Crypto++).

It's also worth nothing that while the splash screen runs, no sound plays on it.

##### Share on other sites
You most likely have a working directory problem where the game can't find your image, sound, and data files. The simplest solution is to open the SDLMain.m file and change the working directory to your app bundle's Resources folder. More detailed information on changing the working directory is in the following article:

SDL Tips for Mac OS X

##### Share on other sites

You most likely have a working directory problem where the game can't find your image, sound, and data files. The simplest solution is to open the SDLMain.m file and change the working directory to your app bundle's Resources folder. More detailed information on changing the working directory is in the following article:

SDL Tips for Mac OS X
I'm not really sure what to do with the code in that article. Objective-C confuses the heck out of me.

Though for what it's worth my resources are actually loading, or at least the images are -- on the splash screen, if I disable SDL_PollEvent, I see the splash screen as it would normally display.

I of course still would like to figure out where to put that code, as having the resources in the app bundle would be quite preferable.

Here's my setupWorkingDirectory code:

/* Set the working directory to the .app's parent directory */ - (void) setupWorkingDirectory:(BOOL)shouldChdir { if (shouldChdir) { char parentdir[MAXPATHLEN]; CFURLRef url = CFBundleCopyBundleURL(CFBundleGetMainBundle()); CFURLRef url2 = CFURLCreateCopyDeletingLastPathComponent(0, url); if (CFURLGetFileSystemRepresentation(url2, 1, (UInt8 *)parentdir, MAXPATHLEN)) { chdir(parentdir); /* chdir to the binary app's parent */ } CFRelease(url); CFRelease(url2); } }

##### Share on other sites
In the file SDLMain.m there is a method called setupWorkingDirectory. Comment out the code inside the method. Paste the following code inside the method:

NSString *resourcePath = [[NSBundle mainBundle] resourcePath]; [[NSFileManager defaultManager] changeCurrentDirectoryPath:resourcePath];

Now the working directory should be set to your app bundle's Resources folder.

##### Share on other sites
[stuff]
Thank you!

So, here's an update. I noticed something interesting in the GDB logs: http://pastie.org/3772361

This happens when SDL.framework is located in both /Library/Frameworks and the application bundle.

If I remove SDL.framework from /Library/Frameworks, the game refuses to open, OS X complaining that the game's not compatible etc etc.

If I remove SDL.framework from the application bundle... the game runs! Until it crashes at Crypto++, anyway (keep in mind that's a statically linked library, not a framework, as that's all I could find for it on OS X).

EDIT: I've narrowed the problem child down to just SDL.framework... the SDL_* frameworks all work just fine.

EDIT 2: Manage to fix Crypto++. So, now all we have to do is get SDL.framework to play nice...