OpenXcom Forum
Contributions => Programming => Topic started by: luciderous on May 16, 2010, 12:49:01 am
-
!!! WARNING !!!
This guide is effectively OBSOLETE and is not supported anymore. Please, use it for historical purposes only - to possibly get a better idea how the process works, but not for the actual compiling itself.
To succeed with you own build, follow the new guide instead - https://openxcom.ninex.info/forum/index.php?topic=127.0
-------
After some fiddling with XCode on my native 64-bit Snow Leopard (10.6.3) I've finally succeeded in building the source. There were (and still are) some peculiarities though. So, how did I do that?
First of all, you need the prerequisites installed. Those would be:
* SDL.framework
* SDL_mixer.framework
* SDL_gfx.framework
You can fetch the first and second one here:
https://www.libsdl.org/release/SDL-1.2.14.dmg
https://www.libsdl.org/release/SDL-devel-1.2.14-extras.dmg
https://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.11.dmg
The problem, however, lies with SDL_gfx, for there is no official precompiled package - you have to create it yourself. However, if you find the process dull or intimidating - here is a precompiled latest version (SVN r45) built by me - https://www.mediafire.com/?h4gor8qrggcc2nw
Also, after the r104 release of OpenXcom - it turned out that 64-bit support in most of those frameworks was kind of messed up, so I had to manually recompile them to get things working again. If you happen to stumble upon the same issues - here goes a bundle of everything you might need - https://www.mediafire.com/?8c69mvblmzod73w
After you have finally got all three frameworks installed (presumably in /Library/Frameworks/) - create a new project in Xcode and select User Templates > Application > SDL Application. Name it "openxcom" (without quotes of course).
Now we have to configure access to SVN-repository so we can stay up to date with project's contributions.
Go to SCM > Configure SCM Repositories > + and enter a name (I chose "OpenXcom") and type (Subversion) for your new repo. Now the tricky part!!! Add THIS address to the URL field -
https:https://openxcom.svn.sourceforge.net/svnroot/openxcom. For some reason the URL given by SupSuper didn't quite work - showed an error.
Once the repo is set up, click SCM > Repositories > "newly added repo" and you should automatically connect to it. Click on "trunk" folder and then execute "Checkout" command from the toolbar. Save the "trunk" folder inside your project folder (that would be "openxcom").
Next, go to Project > Select Project Settings > General and click "Configure Roots & SCM". Under "Root" tab enter "trunk" (without quotes) and your repo will be suggested automatically. Ok.
Right-click on "openxcom" project tree in the left pane of main window and select Add > Existing Files > path to "openxcom" > trunk.
Ok, SVN is set and in sync, now you have to add yet missing frameworks to your project. Right-click on Frameworks > Linked Frameworks folder in the left pane and select Add > Existing Frameworks > SDL_mixer.framework and then follow the same procedure to import SDL_gfx.framework. Next, drag-n-copy those frameworks from "Linked Frameworks" to "Targets > openxcom > Copy Frameworks into .app bundle" to make the bundle self-sustainable.
Then, go to Project > Edit Project Settings > Build and make sure that in "Search Paths" section you have the following strings:
Corresponding to "Header Search Paths" you should add "$(HOME)/Library/Frameworks/SDL_mixer.framework/Headers", "/Library/Frameworks/SDL_mixer.framework/Headers", "$(HOME)/Library/Frameworks/SDL_gfx.framework/Headers", "/Library/Frameworks/SDL_gfx.framework/Headers".
One more thing - go up the list in this tab, select "All Configurations" from the "Configuration" drop-down menu, and corresponding to "Base SDK" key choose "Mac OS X 10.6" value. This will make sure that your program will use the latest features provided by OS X. However, if you want your app to be reasonably backwards-compatible make sure to select earlier target value (my recommendation would be 10.5.) corresponding to "Mac OS X Deployment Target" key.
Now we want to make sure that the original game data we feed to this engine will be read from within the bundle's "Resources/DATA" folder, so our game is fully self-contained OSX-style. You have to edit "SDLMain.m" file (click on "Classes" folder in the left pane of you Xcode project window) as described here https://meandmark.com/blog/2009/12/sdl-tips-for-mac-os-x/.
Ok, now you can choose "Build" command from the menu and hopefully see everything compile without a hitch (due to many reasons your experience may vary, of course :)
Find your newly built app, open it (right click on it > Show Package Contents > Contents > Resources > DATA) and put the original UFO Defense data folder tree (I had the Windows version, but DOS data should work as well) there and you are done.
Now you can click on your app, and if everything was done right - you should experience some oldschool wonder. Enjoy! ;)
P.S. For those of you who have troubles with this setup - here is a precompiled binary (constantly updated), created by following the aforementioned step-by-step guide.
v. 0.1 (upd) (SVN r214) - https://www.mediafire.com/?p1wh3l7195kfpqr
-
Thanks for the help, I've put up your build (can't try it myself though) and link to the instructions on the website if that's ok with you. :)
Go to SCM > Configure SCM Repositories > + and enter a name (I chose "OpenXcom") and type (Subversion) for your new repo. Now the tricky part!!! Add THIS address to the URL field -
https:https://openxcom.svn.sourceforge.net/svnroot/openxcom. For some reason the URL given by SupSuper didn't quite work - showed an error.
I've corrected the link now, you could've also used https:https://openxcom.svn.sourceforge.net/svnroot/openxcom/trunk/ to avoid the subfolder.
-
That's perfectly fine with me. In fact, I am eager to help you with this one, if you don't mind. I am in possession of iMac with OSX on it (obviously), and I'm very interested in your progress on this project, so it's mostly scratching my own itch here :D
And of course, I can help with some testing/bug-spotting too. Not much on a programming side though. Not yet, at least :(
-
Someone posted this on another forum:
When I attempted to run Openxcom, it gave an error saying I might not have the right OSX for it. I have 10.6.3, do you know what version do I need to make it work?
-
Someone posted this on another forum:
When I attempted to run Openxcom, it gave an error saying I might not have the right OSX for it. I have 10.6.3, do you know what version do I need to make it work?
It seems I've left a build option "active architectures only" for that previous build. And since my working arch is x86_64 - that quite possibly may be the culprit. I'm going to make a new build with more compatibility turned on. However, there is a file missing in the trunk - https://openxcom.ninex.info/index.php/2010/05/random-numbers-suck/#comments and thus I'm stuck at this point until it reemerges there ::)
-
Someone posted this on another forum:
When I attempted to run Openxcom, it gave an error saying I might not have the right OSX for it. I have 10.6.3, do you know what version do I need to make it work?
It seems I've left a build option "active architectures only" for that previous build. And since my working arch is x86_64 - that quite possibly may be the culprit. I'm going to make a new build with more compatibility turned on. However, there is a file missing in the trunk - https://openxcom.ninex.info/index.php/2010/05/random-numbers-suck/#comments and thus I'm stuck at this point until it reemerges there ::)
I have saved the missing file. :)
-
I hope my new build will fix the problem.
* The guide is updated as well - please, read it thoroughly - now you put data files INSIDE the bundle (Resources/DATA).
-
I finally had a chance to get on a Mac and try this myself. Here's some issues I ran into:
Running your build: The application only includes the SDL.framework, it's missing SDL_mixer.framework and SDL_gfx.framework.
Compiling it myself: I got the application and all the frameworks set up fine. My only problem is SDL_gfx. I figured out how to compile the source into a framework with Xcode, my only problem is it's stuck building only for "i386" architecture, even though Active Architectures Only is disabled and all the available Architectures seem to be listed. Any idea what the problem might be?
Also, regarding this step:
One more thing - go up the list in this tab, select "All Configurations" from the "Configuration" drop-down menu, and corresponding to "Base SDK" key choose "Mac OS X 10.6" value.
I set it to "Mac OS X 10.4" and that seemed to work fine. If that affects backwards compatibility, I'd like if it worked on as many versions as possible.
Everything else seems fine though. :) I might commit the Xcode project once this is done to save all those steps.
-
+Guide updated
Running your build: The application only includes the SDL.framework, it's missing SDL_mixer.framework and SDL_gfx.framework.
Sorry, my bad. Fixed!
my only problem is it's stuck building only for "i386" architecture,
Architectures = Standard (32/64-bit Universal)
Valid Architectures = list all requested archs
Clean all targets and try to build again. Should help.
Please note, in order to have all the headers copied into .framework bundle you should check them as "Public" in "Targets > SDL_gfx > Copy Headers".
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. Yet this is unnecessary, sinse "Base SDK" key has nothing to do with compatibility - it only determines what new features you can employ. To set the app to be backwards-compatible you should check the version needed corresponding to "Mac OS X Deployment Target" key. More on that here - https://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/cross_development/Introduction/Introduction.html
Of course, setting compatibility to some obscure version would need all the dependent frameworks to be recompiled with those options in mind, and that is quite an achievement. 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.
-
I got it all working now. :) Seemed a bit slow, but that might just be crappy university Macs at work...
And as long as it works on typical Mac systems I'm happy, I just wanted to make sure it ran on more than the latest brand new updated state-of-the-art Mac OS X or something... thanks for clearing that up. I'll put up my Xcode project soon for any other Mac users, although it's still not my platform of choice so you can keep maintaining and testing it. ;)
P.S. The README in the SVN is meant for developers, so not sure if it's worth including in builds, it might just confuse users.
-
so you can keep maintaining and testing it.
My pleasure! 8)
Concerning README - I see no problem there, since common users will never download source code in the first place. So only developers will read it, as intended.
-
so you can keep maintaining and testing it.
My pleasure! 8)
Concerning README - I see no problem there, since common users will never download source code in the first place. So only developers will read it, as intended.
Well I found it in the Resources of your Mac build, which is why I mentioned it. ;)
-
Oops. :D
-
SVN build 99 does not compile correctly. Currently it says:
openxcom/trunk/StartState.cpp:100: error: expected primary-expression before '}' token
openxcom/trunk/StartState.cpp:100: error: expected `;' before '}' token
That's line 100, a parenthesis right after "default:" statement. Seems something went missing there. BTW, the previous 98 build compiled just fine, so this could possibly be related to some later cleanups.
-
SVN build 99 does not compile correctly. Currently it says:
openxcom/trunk/StartState.cpp:100: error: expected primary-expression before '}' token
openxcom/trunk/StartState.cpp:100: error: expected `;' before '}' token
That's line 100, a parenthesis right after "default:" statement. Seems something went missing there. BTW, the previous 98 build compiled just fine, so this could possibly be related to some later cleanups.
Should be fixed now, these cleanups never seem to end. :P
Would you mind making a new Mac build soon? I hope to put some new out eventually.
-
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?
-
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.
-
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.
-
Here is a patch for SoundSet.cpp. On my x86_64 GNU/Linux system game crashed on line 86 of SoundSet.cpp:
name = new char[namesize];
There were no error message, it just crashed with the following message, backtrace and memory map:
*** 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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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!
-
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!
-
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.
-
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/ (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.
-
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.
Yeah, it's not installed by default. If you go back to the XCode 3.2.x installer, i think under [Installation Type] you can turn on the optional stuff. MacOSX10.4u.sdk should be one of the options. I don't have it in front of me, but that's what i remember.
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/ (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.
I'm *not* trying to start an argument, but your data shows that Tiger users are over a fifth of the market. Again, unless there is a major burden supporting that particular compilation target, i would argue against turning our backs on millions of potential users. And yes, i do intend to help share the burden after i get up to speed.
-
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?
SDL_gfx includes an XCode project in the "Other Builds" folder, after upgrading and tweaking it should work fine.
I might commit the Xcode project once this is done to save all those steps.
Please do!
I no longer have access to a Mac so I can't maintain an Xcode project, you'll just have to follow marabus' instructions or ask him to post one.
-
The problem, however, lies with SDL_gfx, for there is no official precompiled package - you have to create it yourself.
Question: do all the dependencies have to be frameworks? I built SDL_gfx using the standard configure/make/make install, which is all i know. I did unpack the optional Project Build stuff and move them in with the other SDL_gfx sources, but can't seem to do much from there - the project.pbxproj loads into XCode as a plain text file and all the target/build submenus are all grayed out. I crawled the web awhile looking for a tutorial, and saw lots of how-tos on making a .pbxproj but none on what to do with one.
-
Question: do all the dependencies have to be frameworks?
Well, theoretically... no. But you are really asking the wrong question here. The "make" utility provides for a building environment only, nothing else. So when employed on OSX it should build any specific target the system requires, and in our case that would be a framework target. You should check it after doing "make install" - whether a SDL_gfx.framework is present in /Library/Frameworks or ~/Library/Frameworks. If not, then you've got a problem there, since it would imply that you have to build the entire OpenXcom+dependecies stack using this method and it would be quite a feat if achieved. And of course, that is not something I'm quite skilled in, not to mention the irrelevance of such a method if there is a full-blown Xcode building environment at your disposal. Therefore I'd strongly recommend you to get better acquainted with Xcode - it is very easy to grasp, and is definitely more logical and less arcane than the whole "make" lingo.
And concerning your lack of luck with .pbxproj files - there is no wonder you've got issues, since these are project files for Project Builder application, the long time obsolete ancestor of Xcode. That is what I meant in the beginning of my "compilation guide" when I mentioned SDL_gfx to be ill-maintained. To get you up to speed fast, I suggest you try my project files instead - https://www.mediafire.com/?k13ii1v0hl6hbai
But be advised that SDL_gfx is dependent on SDL.framework, so the latter should be installed preliminary at a designated location in order for SDL_gfx to build successfully.
P.S. There is quite a good reading on frameworks in case you need to dwelve further - https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html
-
IIRC, I managed to get SDL_gfx built just by renaming the included file in "OSX-PB-Xcode.zip" from .pbproj to .xcodeproj, so Xcode would open it and automatically upgraded it, and then I fixed up any remaining errors. Maybe I just got lucky. :P
-
<snip>
The "make" utility provides for a building environment only, nothing else. So when employed on OSX it should build any specific target the system requires, and in our case that would be a framework target. You should check it after doing "make install" - whether a SDL_gfx.framework is present in /Library/Frameworks or ~/Library/Frameworks. If not, then you've got a problem there, since it would imply that you have to build the entire OpenXcom+dependecies stack using this method and it would be quite a feat if achieved. And of course, that is not something I'm quite skilled in, not to mention the irrelevance of such a method if there is a full-blown Xcode building environment at your disposal. Therefore I'd strongly recommend you to get better acquainted with Xcode - it is very easy to grasp, and is definitely more logical and less arcane than the whole "make" lingo.
I agree that 'make' builds what is required for the target system. Let me offer a slight correction: frameworks are not required by OSX. I've built scores of packages through fink, and none of those created a framework. Apple may prefer frameworks, but dylibs and such still work fine. I know this much, since i volunteer as a package maintainer for the freeciv package in fink. In answer to your question, SDL_gfx installed into /usr/local/libs. It wasn't particularly hard to add the header files to the XCode project alongside the other files, but i'll take your advice and rebuild SDL_gfx. I do also intend to learn more about XCode, but haven't yet found a good starting point. I will say this, though: the average linux user can build most anything with just "./configure;make;sudo make install". No special forms of logic are needed for the end user, though developers do need to be skilled in the arcane. There might be some exceptions in the world of Gnome, however.
And concerning your lack of luck with .pbxproj files - there is no wonder you've got issues, since these are project files for Project Builder application, the long time obsolete ancestor of Xcode. That is what I meant in the beginning of my "compilation guide" when I mentioned SDL_gfx to be ill-maintained. To get you up to speed fast, I suggest you try my project files instead - https://www.mediafire.com/?k13ii1v0hl6hbai
But be advised that SDL_gfx is dependent on SDL.framework, so the latter should be installed preliminary at a designated location in order for SDL_gfx to build successfully.
P.S. There is quite a good reading on frameworks in case you need to dwelve further - https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html
I will investigate that reading closer, thank you. However, i question the wisdom of relying upon a dependency as dodgy as this, but of course that's all up to SupSuper!
-
IIRC, I managed to get SDL_gfx built just by renaming the included file in "OSX-PB-Xcode.zip" from .pbproj to .xcodeproj, so Xcode would open it and automatically upgraded it, and then I fixed up any remaining errors. Maybe I just got lucky. :P
Maybe. I renamed "project.pbproj" -> "SDL_gfx.xcodeproj". Finder now knows XCode is the default program to open this kind of file. However, there must be something internal to the file that throws off Leopard: Finder sees the file as type "Document", while other .xcodeproj files are seen as kind "XCode Project File". In any case, the renamed file is loaded into XCode as a text file - not the desired behavior. I suspect xcodeproj files are internally built as xml/plist type databases, and the older version is lacking some nodes that XCode 3.1+ needs.
I then attempted using marabus' version, and ran into many more problems. 1) This particular project file is closely tuned to marabus' personal file storage system, and wasn't able to find any of the sources in SDL_gfx-2.0.22 when i moved it there. 2) It wouldn't work for me, since it is hard-coded to build for 64 bits and 10.6, neither of which are available on my wife's Mini. 3) After i corrected for the above as well as i could, the build errors out with:
_SDL_framerateDelay in SDL_framerate.o
symbols not found
SDL_framerate.o does exist, and i'm not really sure at this point what else to look at.
-
Funny, Xcode's supposed to be backwards-compatible from what I read. Maybe it was the other PB project. Guess it doesn't matter.
I will investigate that reading closer, thank you. However, i question the wisdom of relying upon a dependency as dodgy as this, but of course that's all up to SupSuper!
If I knew of a better solution I would use it.
-
I contacted the SDL_gfx author about it, he knows the included XCode project is outdated since it was sent in by contributors long ago. However if you have an updated working project you can send him and he'll add it to the next build.
Also:
I do have a Mac, but usually build SDL_gfx via autoconf (configure/make) - presumably this works, since I have fink/macports installed.
-
I'm glad to announce that this thread is now officially obsolete and recommend it to be deleted altogether.
Here is a new champion - https://openxcom.ninex.info/forum/index.php?topic=127.0
8)
-
So we're already not supporting Tiger, and now you want to drop support for Leopard, as well? That's about two fifths of all Macs that can't afford the latest and greatest... Could we please make this project a little more elitist?
-
Dentrassi_BBQ, not to make an argument or anything, but the compilation guide is made the way it is because that's the software I personally use. So unless you are eager to contribute to the project by building it on your platform and your way, it can't be helped.
And as I noticed earlier, the step-by-step instructions should be the same for prior Mac OS X versions as well, with minor changes in build parameters that would be obvious to anyone at least distantly aquainted with Xcode. If you won't compile it yourself, there is a prebuilt binary that DOES (or at least should) work on 10.5 Leopard. Hope that clears any misunderstanding.
-
Look, i really want to work with you on this, but Freeciv is ramping up right now for a new unstable release, and a new stable release right behind it. After that i need to focus on semester finals. I should have more time around the end of December.
That being said, it is one thing to start a new topic called "Compiling on Mac OS X Snow Leopard..." and entirely something else when you ask that the more inclusive topic about compiling for OSX be deleted. That implies that users who don't have SL shouldn't even be able to access the information that has previously been put together for them. Please inform me how i misunderstood that.
I will give your binary another go. Last time i tried, it was looking for dependencies in some obscure directory like /usr/local/Cellar/ , which i assume only exists on your particular setup.
-
That implies that users who don't have SL shouldn't even be able to access the information that has previously been put together for them.
Well, that would be true if the original guide did contain the info on the build process for legacy OSX versions. And had you been thorough on reading it, as well as reading the new guide - there would be no impied meanings for you. You would clearly see that the new guide is simly a simlification of the old one, a cleaning of the mess, to be precise. I use the same SDK, same Deployment Targets. Nothing else changes.
However, if you think that the original guide will be of any real help to you, despite my explanation - be my guest, if you don't want me to make your life easier, than who am I to deny you the opportunity to get your hands dirty? ;)
-
I'm having another go at this, but still having problems. I have installed the framework versions of SDL and SDL_mixer [in /Library/Frameworks/]. Now when i go to build SDL_gfx it claims that SDL isn't installed. Before i dump the frameworks and build SDL from scratch, is there something else i should try?
-
is there something else i should try?
Well, you should definitely try the supported build process, as laid out here - https://openxcom.ninex.info/forum/index.php?topic=127.0 ;)
However, if you persist on moving on with your own painful but nevertheless gratifying experience, and are in need of an advice - you should provide a bit more info on what you are currently trying to achieve. From what you've written, I presume you are trying to build SDL_gfx from scratch. Are you using the latest template I provided for the project? Or have you just started a new Xcode project? In the latter case you should make sure you've linked the SDL.framework to your target and have specified the correct path to it in the build configuration. Hope that helps.
-
I'm following https://openxcom.ninex.info/index.php/compiling/ (https://openxcom.ninex.info/index.php/compiling/). The links for SDL and SDL_mixer both lead to binary packages, while link for SDL_gfx does not. If there's another source for this package, i must be missing it.
As usual, i do take issue with the so-called 'supported build process' being labelled "Compiling on Mac OS X Snow Leopard ...". I'm not building for Snow Leopard, so your thread would not seem to apply.