Installation on Mac OS X

[exile]

Thank you for such a great initiative that is GemRB! I hope that this project continues to fix bugs and implement the missing things as it really keeps the IE games alive.

 

I saw that some users have problems installing GemRB for OSX (me included) - i believe that most OSX users try to do this to be able to play PST - other IE titles have been ported for the platform.

 

This post is not meant to be a complete tutorial but tries to help in the right direction.

 

If somebody finds some of this useful, don't hesitate to include it into some other complete tutorial or documentation as seen fit (credit, where credit is due) or even alter the autogen script so that on OS X the variables would be set correctly. For example the system is able to correctly find the bundled Python framework but not the OpenAL framework

 

The below is valid for Mac OS X 10.5.2 (Leopard) and GemRB 0.3

 

1. Dependencies - Some of the dependencies listed for GemRB are shipped with leopard - this includes OpenAL and Python, but some are missing - to get the rest, install MacPorts from macports.org - please note that MacPorts itself has some special requirements like XCode prior to installation.

 

My goal was to only install things that Mac OS X does not include by default.. you can of course compile your own python and\or openal.

 

After MacPorts installation install the missing dependencies:

 

sudo port install libsdl +quartz
sudo port install libpng

 

zlib gets also installed as a dependency among libsdl and libpng

 

Now after getting the GemRB sources and unpacking them to a location by your preference, it's time to configure it as per instructions - so run something like:

 

./configure CPPFLAGS="-I/System/Library/Frameworks/OpenAL.framework/Headers -I/opt/local/include" LDFLAGS="-L/opt/local/lib" --prefix=$HOME/bin/gemrb

 

The prefix specified the location where GemRB will be installed The CPPFLAGS and LDFLAGS are needed for the configuration part to succeed. If the configure script fails with notification that the -lopenal cannot be found change the configuration script

 

LIBS="-lopenal $LIBS"

change to:

LIBS="-framework OpenAL $LIBS"

 

when compiling with make. There can be errors about al.h and alc.h not found. Edit the respective files that are reported and remove the AL/ part of the reference to the files. Remember that through the CPPFLAGS we showed where to find the OpenAL headers.

 

Some Makefiles might still include the -lopenal reference to linking, you should change them to the -framework OpenAL like:

 

./gemrb/plugins/ACMImporter/Makefile:OPENAL_LIBS = -framework OpenAL
./gemrb/plugins/ACMImporter/Makefile:libACMImporter_la_LDFLAGS = -module -version-info 0:0:0 -L/opt/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -lpthread -framework OpenAL
./gemrb/plugins/MVEPlayer/Makefile:OPENAL_LIBS = -framework OpenAL
./gemrb/plugins/MVEPlayer/Makefile:libMVEPlayer_la_LDFLAGS = -module -version-info 0:0:0 -lpthread -framework OpenAL
./Makefile:OPENAL_LIBS = -framework OpenAL

 

In the GemRB linking phase you might get the following error:

 

Undefined symbols: "_main", referenced from: start in crt1.10.5.o

 

This is actually caused by SDL - I corrected this by adding some more LIBS to link with to ./gemrb/Makefile

 

 

LIBS = -lpng -lz -lSDL -lSDLmain -framework Cocoa

 

If the Make succeeds just install it using make install it should complete without errors - your GemRB should be ready for action (theoretically)

 

If you are running on PPC you have to add EndianSwitch=1 to the GemRB.cfg

 

As noted this is not meant to be a complete tutorial - more like giving a start at doing things. If you hate MacPorts you might like to know that actually zlib is shipped with Leopard (/usr/lib/libz.dylib) and SDL actually can be aquired as a ready built framework for Mac OS X which you can install to /Library/Framework/*. I'm sure that the same can be said also for libpng.

 

MacPorts however helps you get all the newest SDL\libpng fixes and updates as they are released easily.

[Avenger]

If you have any patch suggestions to the current gemrb makefiles that could (automagically and without breaking existing platform compatibility) detect the framework stuff and compile better on mac platforms, then please submit them.

 

Either here, or by the SF tracker.

[exile]

Thanks for that, the problem is that I have no efficient way of testing if I break something on other platforms in the process. I'm not too fond of automake myself.

 

In my eyes configure is good between linux/unix systems where you have the same things but just in different places. Or for big software projects which are very module based so that you can choose what to include and what not.

 

In case of OS X and frameworks, there's no *-config scripts to call. As I understand there's no optional things that can be compiled to GemRB so configure doesn't really help in shaping up the GemRB either. OS X although unix at it's heart is quite unorthodox compared to others.

 

For OS X users I'd believe the easiest choice would be to:

 

a) Use a monolithic approach and make a separate static Makefile (SDL style..)

a user might just call it with make -f Makefile.OSX or similar and boom it works ☺

b) Create a XCode project and include it into the source tree as Xcode is prequisite to any compiling on OS X anyway - then compile it through that. Although this is nice, if the project main development is not done using XCode then it most often is not kept totally up to date and thus does not work.

 

The only patch I can think of is actually concerning the al.h and alc.h as if compiling under Leopard the location of the header files are directly under /System/Library/Frameworks/OpenAL.framework/Headers

This was the only code change I made… then again some others might disagree with this..

 

--- ./gemrb/plugins/ACMImporter/orig.ACMImp.h	2008-03-18 20:29:44.000000000 +0200
+++ ./gemrb/plugins/ACMImporter/ACMImp.h	2008-03-18 20:38:01.000000000 +0200
@@ -28,7 +28,7 @@

class AmbientMgrAL;

-#ifndef WIN32
+#if !defined( WIN32 ) && !defined( __APPLE__ )
#include <AL/al.h>
#include <AL/alc.h>
#else

--- ./gemrb/plugins/ACMImporter/orig.AmbientMgrAL.h	2008-03-18 20:38:36.000000000 +0200
+++ ./gemrb/plugins/ACMImporter/AmbientMgrAL.h	2008-03-18 20:39:29.000000000 +0200
@@ -27,7 +27,7 @@
#include <string>
#include <SDL_thread.h>

-#ifndef WIN32
+#if !defined( WIN32 ) && !defined( __APPLE__ )
#include <AL/al.h>
#include <AL/alc.h>
#else

--- ./gemrb/plugins/MVEPlayer/orig.mve_play.cpp	2008-03-18 20:47:11.000000000 +0200
+++ ./gemrb/plugins/MVEPlayer/mve_play.cpp	2008-03-18 20:46:01.000000000 +0200
@@ -21,7 +21,7 @@
#endif

#if defined(AUDIO)
-# ifndef(_WIN32)
+# if !defined( _WIN32 ) && !defined( __APPLE__ )
#  include <AL/al.h>
#  include <AL/alc.h>
# else

[Avenger]

Yes, we already have a Win32 dir in SVN for makefiles on the windows platform.

So an OSX/XCode tree would be nice too.

[Guest SyntaxError]

So I was able to download and compile this just fine on Mac OS 10.6.7, however, when I run it it tells me GemRB.cfg cannot be found even though it is in the same directory as the executable and I have full permission to the file. Any advice? I was able to create a gemrb.cfg file in the laternate /usr location, but that is not ideal.

 

One additional question about the mac build:

 

the mac version of SDL is a framework and cant be found by cmake as "SDLmain" changing that to just SDL will let cmake build the make file, but then the linker fails because of a missing SDL symbol. A bit of research turned up that I needed to compile the SDLmain.m file supplied with the framework into the project to resolve that symbol but i was unsure of where that should go. I presume those mac specific SDL files would need to be included somewhere in the gemRB source with an #if defined(__APPLE__) block.

 

Anyhow I didnt want to muck with the source code so I just downloaded the SDL source and built it as a dylib with a libSDLmain.a file to boot so I changed the cmake configuration back to "SDLmain" It would definitely help less savvy mac users to use this if they could just use the framework distribution of SDL instead of having to build it.

 

Thoughts?

[lynx]

you can specify the path to the config with -c. The sdl issue on mac is unrepairable as far as I've heard.

[Guest SyntaxError]

you can specify the path to the config with -c. The sdl issue on mac is unrepairable as far as I've heard.

 

When school is out in July I may devote some of my free time to throwing together some mac build patches to try and resolve the SDL framework issue among other things. At the very least throw together an up-to-date guide to build for mac.

[Guest SyntaxError]

So I decided to add an xcode project to gemRB to facilitate building an iOS version and try and improve the os x build. I am currently running into some compile errors involving function prototypes not matching their candidates; all are unsigned int vs ieDword

 

Example:

 

error: prototype for 'void Inventory::KillSlot(unsigned int)' does not match any in class 'Inventory'

error: candidate is: void Inventory::KillSlot(ieDword)

 

I'm really rusty with c++, but im sure i can figure this out. However, if anybody here happens to know the solution feel free to share it.

 

there are also a number of call of overloaded X is ambiguous error, but other than that everything compiled fine.

[Guest SyntaxError]

I really didnt want to alter the GemRB sourcecode to get this to compile, but the only way i could move past those errors was to change the function definitions... Is there a reason they dont match? This compiles no problem using cmake so what is cmake doing? some fancy gcc flags?

[Avenger]

No, it was an oversight, we'll fix it.

[Guest SyntaxError]

No, it was an oversight, we'll fix it.

 

thats good to hear but im still curious how this was able to compile. I searched the gcc docs for some flag to treat that as a warning or something but i couldnt find anything. I'm only assuming that the cmake route uses gcc does it use clang (or whatever it is) or something?

 

Simply changing the function definitions in the headers let it compile but then the linker complained about missing symbols because it was expecting the unsigned int versions instead of the ieDword. So I'm guess i should go find all the places the code is passing an unsigned int to these function and either chage it to ieDword or cast it?

 

I would be happy to do this for you if it helps. Id rather you spend your time on things over my head

[lynx]

ieDword is typedefed as an unsigned int (with size depending on the platform, see ie_types.h), but this was just a definition/declaration mismatch that wasn't problematic on systems where ieDword is just an unsigned int.

[Guest SyntaxError]

I wish I could remember c++ better and knew more about compilers and linkers because I cannot get this to link.

 

Changing the unsigned int to dwords lets it compile but every function i changed now becomes a missing symbol.

 

example:

changed void Actor::SetFistStat(unsigned int stat) to void Actor::SetFistStat(ieDword stat)

and now the linker complains that void Actor::SetFistStat(unsigned int stat) is a missing symbol. the mangled symbol it is looking for is __ZN5Actor11SetFistStatEj but the symbol in Actor.o is __ZN5Actor11SetFistStatEm

 

Actor.h and Actor.cpp both have the definition as void Actor::SetFistStat(ieDword stat) except the cpp implementation is also static.

 

exact error from linker:

"Actor::SetFistStat(unsigned int)", referenced from: Interface::LoadGemRBINI()      in Interface.o

 

I dont know how or why the linker is looking for that or how to fix it.

 

I get no symbol link errors for any functions other than the ones i changed. its almost as if the compiler and linker are seeing the typedef of ieDword differently.... any ideas? special linker/compiler flags im missing?

 

here is my config.h:

#define HAVE_CONFIG_H 1

#define PACKAGE "gemrb"

#define SIZEOF_INT 4
#define SIZEOF_LONG_INT 8
#ifndef HAVE_SNPRINTF
#define HAVE_SNPRINTF 1
#endif
#ifndef HAVE_STRNDUP
#endif
#define HAVE_FORBIDDEN_OBJECT_TO_FUNCTION_CAST 1
#define PLUGINDIR "/Library/Application Support/gemrb/plugins"
#define DATADIR "/Library/Application Support/gemrb"
#define SYSCONFDIR "/Library/Application Support/gemrb"

[Guest SyntaxError]

sorry for being such a spammer!

 

I figured it out. I was right about the linker and compiler seeing the typedef differently and all i had to do was move "HAVE_CONFIG_H 1" out of the config.h file (DUH!!!) and into my apple specific project header file.

 

Compiles and links fine now! I still need to setup the gem rb resources and config files before I will know if this is fully successful.

[Guest SyntaxError]

I believe I have something of value to commit to the project regarding building for OSX/iOS.

 

I have created an xcode project to build gemrb that:

1. replaces the *nix paths with apple appropriate equivalents.

2. removes the dependancies on building SDL unix style and instead links against the sdl OS X framework as well as linking against the OpenAL and Python Frameworks that ship with OS X + libzlib that also comes with os x

3. builds gemRB as an application bundle (complete with gemRB icon) instead of a commandline executable.

 

I would like to also include libpng.dylib as a build resource if that is permissible with both gemrb and libpng folks.

 

 

Anyhow how do I commit my work? the only cross platform source code I changed was the previously mentioned header files that are going to be changed anyhow; everything else I added is in a special apple directory and uses for the xcode project only.