next »

[Hinchy]

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.)

Code:

#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.

[cplhasse]

I've only ported an SDL project to Mac once and it was a while ago so I probably can't help you much, but the problem is probably with XCode (if that's what you're using). If you're new to XCode (like I) it's easy to screw up the project configuration. Best I can do is point you to a configuration guide:

http://www.noquarterarcade.com/xcode-sdl-development-setup

Might not be what you need, but worth a try =

[ThemsAllTook]

The preferred method of library distribution on OS X is through frameworks

Preferred by some, but lots of devs will be happier with a static library and headers.

Code:

#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

Dunno if that's literally your code, but #elseif is definitely not the directive you want there. #else is what you want (if you want a preprocessor else-if, it's #elif).

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.

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.

Presumably what's happening is that your #elseif directive simply gets ignored (I'd expect it to generate a warning at the very least; compiling with -Wall -Wextra -Wno-unused-parameter -Werror is highly recommended), and none of these headers are getting included at all on Mac OS X. If the SDL header path is still a problem after fixing that, you might be able to get around it by specifying the right header search path option with -I.

Hope that helps!

[Hinchy]

Wow, I feel like a huge derp. That was the problem.

Now it compiles, but I'm getting a EXC_BAD_ACCESS crash 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.

[mcc]

Did you call SDL_init and such (I assume so or it would not work on non-mac platforms)

Are you doing the bonus SDLMain.m magic or are you just compiling against the SDL library and expecting that to work

SDL on mac generally requires some extra setup code that runs before your main() does

[Hinchy]

Did you call SDL_init and such (I assume so or it would not work on non-mac platforms)

Yes.

Are you doing the bonus SDLMain.m magic

Yes.

[Richard Kain]

Did you link to the frameworks in question? On mac, you generally need to link to the frameworks in your IDE. This should be possible no matter what IDE you are using. I'm using SFML on mac, and I got the linking working in XCode as well as Code::Blocks. In XCode you need to go to the settings for your project, select the project target, and then open the bar for framework linking. In Code::Blocks you would select the properties for your project, then select the project build options, and then go to the linking tab. There is a panel there where you can input "-framework OpenGL". Of course, in your case you would probably input "-framework SDL".

Don't know if this will help, but it was a headache I was dealing with a week ago.

[mcc]

I think Kain is asking a good question.

EXC_BAD_ACCESS in pollevent i could imagine being a number of things, but if you're ALSO getting crashes in crypto++? That sounds to me like a more serious problem where probably memory is getting corrupted early. This could be something like importing a framework incorrectly, it could also be something totally unrelated to SDL (i.e. maybe heap gets corrupted and this causes SDL to crash, rather than SDL corrupting the heap).

You might also want to be aware SDL has its own forum if we can't figure this out.

[Hinchy]

[words]

Yes, my frameworks are being linked. I wouldn't be able to see the title screen otherwise, as mentioned earlier.

EXC_BAD_ACCESS in pollevent i could imagine being a number of things, but if you're ALSO getting crashes in crypto++? That sounds to me like a more serious problem where probably memory is getting corrupted early. This could be something like importing a framework incorrectly, it could also be something totally unrelated to SDL (i.e. maybe heap gets corrupted and this causes SDL to crash, rather than SDL corrupting the heap).

I'm intrigued by this but I have no idea where to begin.

[Hinchy]

Update:

Noticed something interesting in GDB logs.

http://pastie.org/3772361

If I remove the frameworks out of /Library/Frameworks, the game refuses to open, OS X complaining that the game's not compatible etc etc.

If I remove the frameworks out of 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).

[mcc]

Update:

Noticed something interesting in GDB logs.

http://pastie.org/3772361

If I remove the frameworks out of /Library/Frameworks, the game refuses to open, OS X complaining that the game's not compatible etc etc.

If I remove the frameworks out of 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).

This is not surprising, if you have run the SDL installer it has hidden a copy of SDL.framework deep in the bowels of /System/Library/Frameworks or somesuch.

However you want your game to load the framework from inside the bundle because otherwise it will run on your computer but then not other people's (because they have not run the installer).

[mcc]

EXC_BAD_ACCESS in pollevent i could imagine being a number of things, but if you're ALSO getting crashes in crypto++? That sounds to me like a more serious problem where probably memory is getting corrupted early. This could be something like importing a framework incorrectly, it could also be something totally unrelated to SDL (i.e. maybe heap gets corrupted and this causes SDL to crash, rather than SDL corrupting the heap).

I'm intrigued by this but I have no idea where to begin.

Possibilities here off the top of my head include
- a mismatch between the headers of the SDL version and the binary of the SDL version you are using (I have seen this happen if you get your framework configuration REALLY messed up)
- some subtle compiler difference in your own code-- for example maybe msvc is initializing variables zero and is gcc not

if i were in this situation-- and i really, really don't think this answer will be very useful, but-- what i would try to do is get debug symbols for crypto++ (I assume this would be easier than debug symbols for SDL), figure out where in crypto++'s code it is crashing, and try to identify why. if a structure that ought to be sound is corrupt, try to breakpoint at an earlier point in the code where it is not yet corrupt and set a memory breakpoint on the structure which later becomes corrupt. this will tell you which piece of code where is messing up the heap.

this would be easier if it were breaking in your code instead of in crypto++ :/

[Hinchy]

However you want your game to load the framework from inside the bundle because otherwise it will run on your computer but then not other people's (because they have not run the installer).

Right, I'm familiar with the drill. So... how could I go about ensuring this happens?

[mcc]

However you want your game to load the framework from inside the bundle because otherwise it will run on your computer but then not other people's (because they have not run the installer).

Right, I'm familiar with the drill. So... how could I go about ensuring this happens?

1. Make sure the frameworks go into the application bundle
2. If the framework that gets copied into the bundle is something other than the system one in library framework, I'd actually suggest removing any copies from library frameworks (so that xcode uses the framework you are trying to put into the application bundle for headers instead of accidentally using the system framework, this happened to me once and it was obnoxious to debug).

[Hinchy]

However you want your game to load the framework from inside the bundle because otherwise it will run on your computer but then not other people's (because they have not run the installer).

Right, I'm familiar with the drill. So... how could I go about ensuring this happens?

1. Make sure the frameworks go into the application bundle
2. If the framework that gets copied into the bundle is something other than the system one in library framework, I'd actually suggest removing any copies from library frameworks (so that xcode uses the framework you are trying to put into the application bundle for headers instead of accidentally using the system framework, this happened to me once and it was obnoxious to debug).

Yeah that's already taken care of. Like I said, the frameworks go into the application bundle, but
-it'll refuse to run at all if there is no SDL.framework in /Library/Frameworks, regardless of whether or not there is a SDL.framework in the app bundle
-it'll crash if there is a SDL.framework in both /Library/Frameworks and the app bundle
-it'll run if there is a SDL.framework only in /Library/Frameworks

(Do keep in mind there are no system-level frameworks for SDL as SDL is not an OS X included library.)

I've also narrowed it down to only SDL.framework exhibiting this behavior (SDL_image and etc play fine).

[BlueSweatshirt]

It sounds like you may have a framework version mismatch or something with the SDL core.

If only SDL core is bugged that might be why polling events caused you an error and not other things.

I'm taking a shot in the dark here because I'm not very familiar with SDL's architecture or how frameworks operate.

[rivon]

Try using Valgrind.

[Hinchy]

I re-made the project and re-imported everything and now it compiles and runs fine.

Welp!

False alarm. We're (mostly) at the same place we were before. I somehow was leaving SDL.framework out of the app bundle, making it load from /Library/Frameworks as it did before.

On the plus side, Crypto++ is no longer giving me grief.

[mcc]

I re-made the project and re-imported everything and now it compiles and runs fine.

Welp!

False alarm. We're (mostly) at the same place we were before. I somehow was leaving SDL.framework out of the app bundle, making it load from /Library/Frameworks as it did before.

On the plus side, Crypto++ is no longer giving me grief.

Wait, I don't understand.

You're saying that if you leave SDL.framework out of the app bundle and force it to load from /System/Library, not only does it compile, you don't get the SDL_PollEvent or crypto++ crashes?

If so is certain, as Jack said you have a version mismatch.

You have apparently two copies of SDL.framework around. One is in your System/Library. The other is somewhere else on your hard drive. You have somehow set your Xcode project to load from the somewhere-on-disk library, and you probably set your header search paths to the system library. When you compile, xcode is getting confused and using part the system library and part the other library, and there are crashes.

You want to find SDL.framework in your xcode project listing, and get info to see where it really is. Whereever the SDL.framework that *isn't* in system library is, delete it. then remove SDL.framework from the xcode project and re-add it, this time making sure to add the System/Library one. Then CLEAN build. I bet this will solve your problem.

[Hinchy]

You have apparently two copies of SDL.framework around. One is in your System/Library. The other is somewhere else on your hard drive. You have somehow set your Xcode project to load from the somewhere-on-disk library, and you probably set your header search paths to the system library. When you compile, xcode is getting confused and using part the system library and part the other library, and there are crashes.

There is no SDL.framework in /System/Library/Frameworks, only in /Library/Frameworks. I am looking at my Xcode project at this very moment, and that is where my Framework Search Paths and Header Search Paths are pointed, this is the file in the Xcode project, this is the file in the Link Binary build phase, and this is the file in the Copy Files build phase.

You want to find SDL.framework in your xcode project listing, and get info to see where it really is. Whereever the SDL.framework that *isn't* in system library is, delete it. then remove SDL.framework from the xcode project and re-add it, this time making sure to add the System/Library one. Then CLEAN build. I bet this will solve your problem.

The SDL.framework in my Xcode project IS located in /Library/Frameworks. This is the only copy of SDL.framework I have installed on my system. I have removed, re-added, and clean built too many times too count.