Compiling OpenXCOM on Mac OS X

[luciderous]

Would you mind making a new Mac build soon? I hope to put some new out eventually.

Done. My pleasure! 
Again, thank you for your efforts (and especially for the latest mouse zoom feature - my long-time dream coming true - I just keep my fingers crossed for your enthusiasm to keep going.

P.S. Perhaps it would be more efficient on my side to notify you every time I make a new build. PM maybe?

[SupSuper]

Would you mind making a new Mac build soon? I hope to put some new out eventually.

Done. My pleasure! 
Again, thank you for your efforts (and especially for the latest mouse zoom feature - my long-time dream coming true - I just keep my fingers crossed for your enthusiasm to keep going.

P.S. Perhaps it would be more efficient on my side to notify you every time I make a new build. PM maybe?

Sure. I haven't noticed if you've been keeping up and just editing your post, so sorry if I missed it and didn't put it on the site.

[luciderous]

r104 has problems compiling - says the SDL and SDL.mixer frameworks miss 64bit functions. Strange...
Nevertheless, temporarily switching the target to i386 only helps, yet the game fais to load completely - it just shows "Loading..." text and hangs the system violently. It's very uncommon to see something reminiscent of BSOD on OS X...
Perhaps the changes in code that load the sounds (Windows only) messed the whole thing up.

[Eeyoocah5Moh]

Here is a patch for SoundSet.cpp. On my x86_64 GNU/Linux system game crashed on line 86 of SoundSet.cpp:

Code: [Select]

name = new char[namesize];

There were no error message, it just crashed with the following message, backtrace and memory map:

Code: [Select]

*** glibc detected *** src/openxcom/trunk/openxcom: malloc(): memory corruption: 0x0000000001ce9ed0 ***
======= Backtrace: =========
...
======= Memory map: ========
...

Obviously, error were not on line 86, but malloc (called by new operator) crashed because of corrupted heap. So with inserting fprintf and malloc here and there to check if the program is still running (with fprintf(stderr, "hi!\n")) and if the heap is still ok (with malloc and new) i was able to find the error. Probably it should work on 32-bit systems but it corrupt memory by buffer overflow on 64-bit systems.

Patch is attached.

I post it here because I think it is related to last post in this thread. Hope SupSuper will read it.

[SupSuper]

I read every post. I've applied your patch, hope that fixes the problem.

Oddly enough, I can't seem to start the game on my Ubuntu system anymore. It compiles fine, but just won't do anything when I run the executable. Hope it's just something with my system and not some bizarro bug.

[luciderous]

r108 - no change The game hangs while loading, and the debugger says: "Error from Debugger: mi_cmd_stack_list_frames: Not enough frames in stack.

[Eeyoocah5Moh]

Oddly enough, I can't seem to start the game on my Ubuntu system anymore. It compiles fine, but just won't do anything when I run the executable. Hope it's just something with my system and not some bizarro bug.

Check different revisions. Some revision should work.

It even don't write anything to stderr and stdout before crash?

[Eeyoocah5Moh]

r108 - no change The game hangs while loading, and the debugger says: "Error from Debugger: mi_cmd_stack_list_frames: Not enough frames in stack.

Try adding some fprintf(stderr, "hello!\n") in different places. Place one in main and move it forward until it don't print anything (the game crashes before fprintf). Then place it inside function where you think game crashes and so on. This is sometimes more useful than debugger, at least you would know where game crashes.

[SupSuper]

Oddly enough, I can't seem to start the game on my Ubuntu system anymore. It compiles fine, but just won't do anything when I run the executable. Hope it's just something with my system and not some bizarro bug.

Check different revisions. Some revision should work.

It even don't write anything to stderr and stdout before crash?

Nope. I stepped line by line with a debugger and found out it got stuck right at the start when initializing SDL_Mixer (so it didn't output any errors), it didn't like 8-bit for some reason, so I changed some parameters around and it seems to work now. I hope SDL_Mixer will automatically handle any format convertions.

r108 - no change The game hangs while loading, and the debugger says: "Error from Debugger: mi_cmd_stack_list_frames: Not enough frames in stack.

I did some more fixes and tried it out on a Mac, got no problems. If you still run into trouble, like Eeyoocah5Moh suggested, you'll have to debug it yourself. Go back to the last revision that worked, compare the changes, see if you can narrow it down to the troublesome lines of code.

[luciderous]

r109 compiled ok. However, I still had to recompile most of the dependent frameworks since they seemed to have 64-bit support messed up. Gonna upload them to mediafire and update the building manual.

[j6cubic]

I can't get the OS X build to run. It attempts to use /Users/vazub/Library/Frameworks/SDL_gfx.framework/Versions/A/SDL_gfx instead of the version inside the bundle. You might want to check your project file.

[luciderous]

Good catch, j6cubic! 
The build was ok, instead it was my unattentive SDL_gfx compiling that did the mishap. Fixed it - just download the new .zip in the first post of this thread.
Thanks for pointing that one!

[Dentrassi_BBQ]

I figured out how to compile the source into a framework with Xcode

It may not be on topic, but i'm probably not the only person who also hasn't figured this out.  Do you have link you could point us to?

I might commit the Xcode project once this is done to save all those steps.

Please do!

[Dentrassi_BBQ]

I set it to "Mac OS X 10.4" and that seemed to work fine.

It seems you have Leopard (10.5) installed. On my Snow Leo, the 10.4 SDK is deprecated, so my best shot here would be to choose 10.5.
<snip>
To be concise, I recommend to set backwards-compatibility to some *reasonable* level, say one step back from current OSX version deployed by Apple. In our case that would be 10.5, 32/64-bit UB and of course - Intel-only. That's because most of Mac-lovers are already here, and if someone needs 10.1 PPC variant - they will have to follow my guide and compile the app themselves - I see no point in supporting all the possible architectures officially.

Deprecated does not mean unsupported.  Apple does still support both PPC and 10.4, and so does our SDL dependency.  In fact, the 10.4 SDK is still delivered as part of XCode, it's just optional instead of automatically installed. 

You are, of course, free to build things however you see fit.  However, i'd like to recommend that the project continue to support two steps back from the current version of OSX.  I don't think that this would prove to be a huge burden.

[luciderous]

Deprecated does not mean unsupported.  Apple does still support both PPC and 10.4, and so does our SDL dependency.  In fact, the 10.4 SDK is still delivered as part of XCode, it's just optional instead of automatically installed.  

Perhaps I'm missing something there? I couldn't find 10.4 SDK anywhere on my Mac partition, and my Xcode refuses to comply as well.

You are, of course, free to build things however you see fit.  However, i'd like to recommend that the project continue to support two steps back from the current version of OSX.  I don't think that this would prove to be a huge burden.

It is a burden in terms of having to deal with SDL dependencies, some of which I had to recompile manually in order to make sure everything worked as intended. And even if manageable, I still see no viable reason why bother in the first place, no offence. If you take a look at these statistics - https://update.omnigroup.com/ (Overall > Major Version), you will notice that 10.4 constitutes only 21.8% of OSX market share and is dropping steadily. Of course, these are not backed by Apple, but I'm sure they are quite representative nevertheless. The aforementioned being taken into account - personally, I think it is not worth the hassle, at least on my part. On the other hand, if you feel comfortable about making such kind of a contribution - you are definitely welcome.