Compiling under OS X [needs compilers/testing]

[Knitter]

Hi,

I'm trying to compile Linwarrior under OS X, Snow Leopard, and would like to know if there are any docs out there that explain how to do it. I don't have much experience with compiling C/C++ software under OS X. Most of my C knowledge was applied in small software that used no libs whatsoever. Also I don't really understand how OS X stores libraries... so any help is appreciated.

Regards,

Knitter

[hc]

Hi, and welcome!

Well, in general there is the short readme which says to run: make clean all
But that's supposed to work on linux - but may work with minor modifications on OS-X or may not.
Linwarrior was already successfuly compiled on FreeBSD with minor modifications - which should be similar ?!

First you'll need the latest linwarrior source release and then:

For compiling you need the gnu compiler collection which should include the "gcc" and "make" tools.
I can't really help you where to get it.

As soon you have those you should be able to type: make clean all
(at a command-line inside the linwarrior directory)

Of course this will probably print a lot of garbage because you probably need some additional headers and libraries installed.

These pages have OpenAL but I dont know wether it they a version fitting your os:
http://connect.creativelabs.com/openal/ ... Items.aspx
http://icculus.org/al_osx/

OpenGL seems to be there, but does it work with gcc?
http://developer.apple.com/opengl

You can get SDL here:
http://www.libsdl.org/download-1.2.php

Maybe this will get you started.

When you get to the point that "make clean all" starts then you are welcome to put it's output here so that we can see what's missing.
Compiler Flags can be changed inside the makefile in the linwarrior directory:
LIBRARIES= ... -lLIBRARYNAME ...
CFLAGS = ...

Anybody else out there with more OS X experience?
I would be very happy if we could get this working!
We could need a helping hand here!

[Knitter]

Hi,

I downloaded the GIT package, made the reset to HEAD and have the code sitting in my computer, so far so good . Building tools are all installed, I don't do much C development but need them for other languages, I think I have all the needed libs, most were installed using macports, I'll have to confirm if they are really all the needed ones since I installed them some time ago.

My problem starts with a CFLAG, namely -std=c++0x that in my system causes the error cc1plus: error: unrecognized command line option "-std=c++0x", removing the flag allows the compilation process to start but shows various errors that I believe are related to the way frameworks are identified in OS X:

...
error: GL/glew.h: No such file or directory
error: AL/al.h: No such file or directory
error: AL/alut.h: No such file or directory
...(several similar to the above)

There are also some like:

source/de/hackcraft/object/cObject.h:246: error: ISO C++ forbids declaration of ‘i’ with no type
source/de/hackcraft/object/cObject.h:246: error: cannot convert ‘__gnu_cxx::__normal_iterator<rComponent**, std::vector<rComponent*, std::allocator<rComponent*> > >’ to ‘int’ in initialization
....
source/de/hackcraft/object/cObject.h:246: error: ISO C++ forbids declaration of ‘i’ with no type
source/de/hackcraft/object/cObject.h:246: error: cannot convert ‘__gnu_cxx::__normal_iterator<rComponent**, std::vector<rComponent*, std::allocator<rComponent*> > >’ to ‘int’ in initialization

As for the file no found errors I believe it's related to how the code refers to the libs, I'll have to see if I can find a way to tell where to look for libraries because I know that, for example, ALUT is in the /Library/Frameworks folder, where frameworks are installed in OS X. If I can solve this problem I can start looking at the others.

Regarding the other errors, may it's because I had to remove the CFLAG? I don't really know much about it . I'll have to find some time to look into it, any OS X user that can shed some light on this?

[hc]

You can try to use -std=gnu++0x instead of -std=c++0x (see Makefile: "CFLAGS += -std=c++0x").
That's going to be replaced anyway because it made trouble with the mingw windows-port, too.
It's used for the new auto-keyword, older releases don't use that one yet.
gnu++0x should be ok if the compiler version is not too old.
The second batch of errors are directly related to this, because "auto" allows things such as:
for (auto i = x; i < y; i++) { ...} // i has automatically the type of x, similar to: for (typeof(x) i = x; i < y; i++) { ... }

error: GL/glew.h: No such file or directory
and so on are from missing libraries/headers.

GLEW: (available for OS X as it seems)
http://glew.sourceforge.net/

AL and ALUT are from the OpenAL-SDK:
See previous post above for links.

More such "error: ...h" could either mean you didn't install the SDK/headers yet or they are in a place your compiler can't find.
In the later case you can add the include path:
See Makefile for "INCLUDES = -I source" and append " -I path/to/directory/where/GL/is/located/in -I path/to/directory/where/AL/is/located/in"


Could you give me the output of "gcc -v"?

[Knitter]

Managed to work around the library problems. I first started to use the LIBRARIES macro that was set in the makefile but realized it was not used where I needed, so I moved all the paths to the INCLUDE macro at the top of the makefile. This sorted things for the libs I had installed using macports but didn't for the other. Let's see if I can explain....

If I use macports, the software is installed into /opt/local, with header files under /opt/local/include and compiled libraries into /opt/local/lib. For these libraries, the code works fine if I add the -I and -L options and specify the correct paths.

For ALUT, and also OpenAL in my case, the libraries are included in /Library/Frameworks and don't have the same name as the one used in the source files. When you include the header <AL/al.h> it doesn't translate to the correct path because in OS X the library is called OpenAL, it's the name of the compiled library. Also there is no AL folder in my system, only a Headers folder. So, setting the -I options with the correct path to my OpenAL installation folder would wield a path like "/Library/Frameworks/OpenAL.framework/AL/al.h". This path is wrong. I don't know of any option that I can pass to the compiler that changes this and I've only seen a workaround with #ifdef/#ifndef macros in the source.

Not wanting to change the source I make a few symbolic links in my OpenAL folder, creating and "AL" link that pointed to the "Headers" folder, and another "AL" link that pointed to the compiled library. This solved the problem with linking to the files.

I now have the other errors related to code errors, that I believe are caused by the removal of the -std=c++0x flag. I'll work those out in a moment, following your suggestions.

To sum things up, this is what I did:

a) change makefile to reflect paths under my system, removed the if clause to confirm that it wasn't causing any problems:

{l Code}: {l Select All Code}

# Project: Linwarrior 3D
# Makefile with auto-dependency generation

# Add Include directories here.
INCLUDES = -I source -I/Library/Frameworks/OpenAL.framework/Headers/ -I/opt/local/include/

# Automatic searching for source files.
# Objects to compile are all sources (cpp) and put the .o below build-dir.
OBJECTS=$(addprefix build/, $(subst .cpp,.o, $(wildcard source/*.cpp source/*/*.cpp source/*/*/*.cpp source/*/*/*/*.cpp source/*/*/*/*/*.cpp source/*/*/*/*/*/*.cpp) ) )

LIBRARIES= -L/Library/Frameworks/OpenAL.framework/ -L/opt/local/lib/ -lGLEW -lGLU -lSDL -lopenal -lalut
TARGET=dist/linwarrior
MKDIR=mkdir -p
RM=rm -f
RMREC=rm -f -r
CP=cp
CPP=c++
LIMITER=/
QUOTE=

#... rest stays the same


b) create a symlink in /Library/Frameworks/OpenAL.framework to the compiled library

{l Code}: {l Select All Code}

ln -s OpenAL AL

c) create a symlink in /Library/Frameworks/OpenAL.framework/Headers to itself making the <AL/al.h> include path valid

{l Code}: {l Select All Code}

ln -s ./ AL

Any thoughts on the mess?

[Knitter]

Neither the c++0x nor the gnu++0x worked.

Searching Google for "os x unrecognized option "-std=c++0x"" reveals 2 results, one that is completely useless and one other that may have my problem http://www.maclife.gr/forum/showthread. ... -compiler-και-std-c-0x. I had to use Google Translate but it seems that that flag is for GCC 4.3, and I have 4.2.1.

Searching for the other flag gives me 0 results!

I'll see what I can do about my compiler version.

[Knitter]

I'm blocked again. After trying to find a suitable 4.3 GCC compiler for OS X and having found none since Apple hasn't supplied any tools beyond 4.2.1 , I installed GCC 4.5.3 from macports, changed the Makefile to use the full path to this new compiler (I don't know how compatible it will be given that it lakes Apple's patches and I've read it may cause problems on Snow Leopard ) and tried to compile again.

Both gnu++0x and c++0x seem to work but OpenAL on OS X doesn't come with alext.h, so I had to comment that in the main.cpp, I think.

After the all adventure I now get compiling errors on OpenAL files ...

/Library/Frameworks/OpenAL.framework/Headers/AL/al.h:87:37: error: '<anonymous>' has incomplete type
/Library/Frameworks/OpenAL.framework/Headers/AL/al.h:87:44: error: invalid use of 'ALvoid'
...

Now, is it something I changed in the Makefile, a flag I'm not giving to the compiler? I looked at the file and there are a few preprocessor macros like TARGET_OS_MAC that I'm not defining and I don't know where they are set, or even if they're being set... is there a way I can confirm what macros are being defined?

Since this may be a bit OS X specific maybe I should take the questions to another board?

[hc]

First I'd like to say that it's ok to stay here with this os x specific topic, esp. because it could help me to make the source more portable or add that to the makefile.
But other boards may be more competent.

Well, it seems you got quite far, and what remains seems to be OpenAL/OS X/Compiler specific.
It may be that newer gcc versions do have problems with statements valid in older versions
(fixing the gnu++0x and getting another problem

As a last resort you may try the older compiler again:
Have a look at the ctrl.h in the linwarrior's source directory (below psi3d) - there still is the old macro code for the "foreach" macro (just exchange the two "for (.." lines):

#define foreach(loopvar, collection) \
for (auto loopvar = (collection).begin(); loopvar != (collection).end(); loopvar++)

//for (typeof((collection).begin()) loopvar = (collection).begin(); loopvar != (collection).end(); loopvar++)

Same for "foreachNoInc".

Other hints/suggestions I can give to what you've tried:
- Headers and Libraries are totally separated things, so you don't need to make a AL symlink for the lib-dir (but a good idea for the headers).
- You could add an empty alext.h to your AL directory instead of changing the source

As for macros like TARGET_OS_MAC these may be set by the compiler itself to indicate the platform (exactly to allow such test cases).
Easily a point of problems when those macros change over time.
Have a look here - another fellow mac user and a hint how to test for those macros:
http://stackoverflow.com/questions/5213 ... eprocessor

[Knitter]

Hi,

After some hiatus I'm back on this problem, whatever I do I can't seem to pass the errors on AL's header files

{l Code}: {l Select All Code}

/Library/Frameworks/OpenAL.framework/Headers/AL/al.h:87:37: error: '<anonymous>' has incomplete type
/Library/Frameworks/OpenAL.framework/Headers/AL/al.h:87:44: error: invalid use of 'ALvoid'
//... some lines after...
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147:120: error: format string argument not a string type


This is using the macports GCC version 4.5.3. Using the stock Apple version will produce several errors and won't compile, even if I comment out the old macro code.

[hc]

Could you post that line from al.h (line 87 plus some lines before)?
Additionally you may mail me al.h .
Maybe google´ing the error messages ("error: ...") may give a clue.

[Knitter]

I've tried to google for it, but I get mixed results. I find some mailing list archives that point to a change in the standard that made code that previously compiled, thought invalid, and stopped compiling in new GCC versions. Most say that the code is wrong and should have never compiled in the first place, but I have to read it with a bigger attention span to see if it's related . I also found one result pointing to a bug in OpenAL code, related to the fact that the code is invalid, but again, my attention to it was a bit low.

Trying to find about the error without adding OpenAL o OS X to the search results in may topics with questions that are answered with the general "that's not C++", or "that's wrong code, it should be...".

I'm afraid I'm only giving this issue a few moments a day and not enough to throughly debug the issue.

I'll mail you the files I'm using.

[hc]

I've had a look at the header you've sent and what google spit out.
From that I'd say change line 87: ALAPI ALenum ALAPIENTRY alGetError( ALvoid );
To: ALAPI ALenum ALAPIENTRY alGetError();
Ie. ALvoid removed
Or to: ALAPI ALenum ALAPIENTRY alGetError( void );

And every other line with errors and ... ( ALvoid ) likewise.
(Line 310 most probably)

As for the reason: I guess it may be hardcoded (or not allowed anymore at all) that a C style function may only have an empty or "void" parameter list (...ALvoid defined as void isn't void enough)... ?!
What's the point in using ALvoid anyway???

[Knitter]

I've had a look at the header you've sent and what google spit out.
From that I'd say change line 87: ALAPI ALenum ALAPIENTRY alGetError( ALvoid );
To: ALAPI ALenum ALAPIENTRY alGetError();
Ie. ALvoid removed
Or to: ALAPI ALenum ALAPIENTRY alGetError( void );

I thought of that but was hesitant to change the code form those headers.

What's the point in using ALvoid anyway???

Nice question to the wrong person ... all these typedefs are a bit useless from my view

Thank you for spending some time on this, I'll try some changes to the headers.

[Knitter]

Another round of "hum... just comment this line here... that line there...."

I removed any reference to ALvoid in al.h and alut.h, ALCvoid in alc.h and commented out an inclusion of a carbon header. Carbon in the latest version of OS X? ...
The alut.h header was including carbon.h header file that was causing the following error:

{l Code}: {l Select All Code}

In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43:0,
                 from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,
                 from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20,
                 from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,
                 from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
                 from mOpenAL.framework/Headers/AL/alut.h:27,
                 from source/de/hackcraft/object/cObject.h:37,
                 from source/de/hackcraft/comp/rWeapon.h:14,
                 from source/de/hackcraft/main.h:17,
                 from source/de/hackcraft/main.cpp:3:
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147:120: error: format string argument not a string type


Removing it allows me to jump over the error but compilation stops on some undefined functions as follows:

{l Code}: {l Select All Code}

source/de/hackcraft/main.cpp: In static member function 'static int cMain::run(int, char**)':
source/de/hackcraft/main.cpp:771:43: error: 'alutInitWithoutContext' was not declared in this scope
source/de/hackcraft/main.cpp:777:65: error: 'ALUT_LOADER_BUFFER' was not declared in this scope
source/de/hackcraft/main.cpp:777:83: error: 'alutGetMIMETypes' was not declared in this scope
source/de/hackcraft/main.cpp:778:67: error: 'ALUT_LOADER_MEMORY' was not declared in this scope
source/de/hackcraft/main.cpp:790:63: error: 'alutCreateBufferFromFile' was not declared in this scope
source/de/hackcraft/main.cpp:945:50: error: 'alutSleep' was not declared in this scope
source/de/hackcraft/main.cpp: In function 'int SDL_main(int, char**)':


I looked at alut.h and there is no "alutInitWithoutContext" function, only "alutInit". I noticed that the code in main.cpp has a commented line, line 770, that shows this function being used before a change to "alutInitWithoutContext". Are these functions and macros defined in the header files you have?

[Knitter]

This is completely insane!

Looking around my files I manage to find that the AL version, official version I must say, for OS X comes with a very simplistic version of the alut.h header file. The file defines no macros and just around five functions. On the other hand, ALUT that I installed along side AL using the files form the ALUT project, provides me with an alut.h header file that is much more complete, and has the functions that previously were causing problems.

I just rigged a few symbolic links and manage to force the usage of the oficial ALUT's headers instead of the AL's ones. So I ended up with some headers from AL's project and others from ALUT's. This got me over the errors related to the Carbon framework, that this new alut.h doesn't even use, and over the missing function and macro definitions.

Still, I now have new errors to show:

{l Code}: {l Select All Code}

In file included from mOpenAL.framework/Headers/AL/alc.h:4:0,
                 from source/de/hackcraft/main.cpp:17:
mOpenAL.framework/Headers/AL/altypes.h:57:22: error: conflicting declaration 'typedef unsigned int ALsizei'
/System/Library/Frameworks/OpenAL.framework/Headers/al.h:74:13: error: 'ALsizei' has a previous declaration as 'typedef int ALsizei'
In file included from mOpenAL.framework/Headers/AL/alc.h:5:0,
                 from source/de/hackcraft/main.cpp:17:
mOpenAL.framework/Headers/AL/alctypes.h:58:22: error: conflicting declaration 'typedef unsigned int ALCsizei'


Notice that I placed the libraries under the working folder so that I could move things around and change whatever I wanted. The errors, though I understand what they mean, make no sense... I'll look into why there are more than one definition of the same thing and see if I can solve that new problem but this is proving to be a quest beyond my knowledge or patience

Wold it be a better option to grab the source for the dependencies and try to compile them myself and use that as a base for building LW? I would really like to have the game compiled under OS X...

[hc]

Don't laugh, but both my linux and my mingw (windows) includes of OpenAL both just use void.

I think Creative's Mac version is similar messed up like their linux """Standard Implementation""" version...but actually the OpenAL version I'm using on linux is OpenAL-Soft (a software implementation which supports more sound-sources btw).
But I don't have a clue how cumbersome it would be to port OpenAL-Soft to mac - also it would be worthwhile the effort if the official OpenAL doesn't work: http://kcat.strangesoft.net/openal.html

[Knitter]

I found that my system was more messed up than I thought. I removed all libraries, symlinks, and any other bit of strangeness and installed all the libraries again, making sure they were placed in the right "mac like" places. I also reduced the number of libraries I was using from macports.

Next I changed the code and added one or two preprocessor conditions so that if a flag was given the includes would follow the names that are used in OS X, #include <AL/al.h> in Linux and Windows but #include <OpenAL/al.h> in OS X.

With these changes, g++ version 4.5.3, no extra include paths in the Makefile the code compiled without errors . Also I changed the way libraries were being referenced, instead of -l flag I used the -framework flag as it's common in OS X. Had to had the SDLmain library too.

Still, even if the code compiles the linking fails I get a "ld: symbol(s) not found for architecture x86_64" error. I believe this usually means that the libraries are not all compiled with the same architecture and that there is one that is 32bit, but I confirmed all libs and they are either 64bit or universal which includes both a 32bit and a 64bit version. Full error message in a pastbin at http://paste.portugal-a-programar.org/p ... ?show=4027

I'll keep looking into this problem, I now have to determine which library is causing the problem, thought the errors are shown as part of SDLmain I don't know if it's really this one.

[hc]

Well one step further!
Glad to hear there is an easier way to get it to compile than editing and linking every header and source.

From those linker errors I would follow that you need to link some platform specific libraries.
Those NS* should be from the NextStep foundation classes.
No clue for CP*/CPS* (try google for those functions without underscores "_" )
Then objc_* the Obj-C runtime lib (worst case scenario: there need to be a objC startup code, a main in objC...basically C will do. But I hope/guess SDL will do that anyways for you).

May be an idea to have a look at what other projects do for porting to Mac, I remember some using special main files just for mac.

[Knitter]

It's alive! It's alive!

As soon as I read your message about "platform specific libraries" it clicked! Cocoa and OpenGL were not being specified in the LIBRARY flag.

This is my Makefile section, I added the usage of "framework" flag in some cases and some missing libraries like SDLmain, OpenGL and Cocoa, also changed the use of alut.h from OpenAL to the ALUT framework I installed:

{l Code}: {l Select All Code}

LIBRARIES= -framework Cocoa -framework OpenGL -L/opt/local/lib/ -lSDLmain -lSDL -lGLEW -lGLU -framework OpenAL -framework Alut
TARGET=dist/linwarrior
MKDIR=mkdir -p
RM=rm -f
RMREC=rm -f -r
CP=cp
# CPP=c++
CPP=/opt/local/bin/g++-mp-4.5
LIMITER=/
QUOTE=

# Adding dummy macro
CFLAGS += -DKNT=1


My change in source/de/hackcraft/object/cObject.h

{l Code}: {l Select All Code}

#include <GL/glew.h>
#ifdef KNT
#include <OpenAL/al.h>
#include <ALUT/alut.h>
#else
#include <AL/al.h>
#include <AL/alut.h>
#endif


and in source/de/hackcraft/main.cpp

{l Code}: {l Select All Code}

#ifdef KNT
#include <OpenAL/alc.h>
#include <ALUT/alut.h>
#else
#include <AL/alc.h>
#ifndef __WIN32
#include <AL/alext.h>
#endif
#include <AL/alut.h>
#endif


As you can see I just added the conditions around what was already defined so that the includes are more "mac like"

Thank you again for the patience, I think we can say that Linwarrior really compiles in OS X without any problems

[hc]

Great!

And thank you for patience, too.

I've found some hints about predefined gcc macros here:
http://stackoverflow.com/questions/2565 ... nd-mac-osx
And here:
http://predef.sourceforge.net/preos.html#sec17

They suggest that you may use __APPLE__ & __MACH__ instead of your custom KNT define to identify OS X

Is it that you are using "/opt/local/bin/g++-mp-4.5" because you've two compiler versions installed and this isn't your default compiler when you use g++? So usually g++ will do, when having only this installation?

BTW you are welcome to post your impressions and suggestions in the Collaboration & Suggestion forum:
http://forum.freegamedev.net/viewforum.php?f=51

And don't hesitate to post runtime problems in the Problems & Support forum.

[Knitter]

The macro was just a temporary solution but those links will come in handy.

The full path to the g++ is due to having the two compilers, I didn't change the selected version in my system, so "g++" is still a link to the Apple' stock version. The one I'm using in the Makefile is the one I installed using macports, and is needed since the Apple's version won't compile the current code. Apple's GCC tools are still version 4.2, and don't support the -std=c++0x nor the alternatives I've tried.

At the moment, for any other OS X user, I would say that to compile LW one needs:
- change the code with the preprocessor macros
- add the missing libraries, SDLmain, Cocoa, OpenGL
- use the frameworks that come with OS X like OpenAL
- install a newer compiler version, since Apple doesn't offer one, not even with the new XCode 4, macports is the easier option
- use the full path to the compiler or use gcc_select to change compiler versions easily
- make clean all, copy linwarrior binary to the same folder as the "data" folder
- run and enjoy

[Knitter]

Hi,

Here is a small patch that will change the code and add some conditions to the Makefile to detect the correct OS, I added an option to detect OS X and maintain the other detection code, almost, unchanged. This change is probably a short term solution, a better approach could be created to detect the correct OS in the Makefile, maybe use things like autoconf/automake (not may area of expertise )

The change to code may be more useful. Even if you ( hc ) don't need it, it could be a faster way to get other users that run OS X on their way to compile the code.

Regards,

Knitter

[hc]

I already planned to add compiler flags for MAC.
Why let that work go to waste.

[Socapex]

Hello, I was in charge of porting manaplus to OSX, and in the process wrote a quite complete guide to releasing a build. It can be found here: http://manaplus.evolonline.org/macosxrelease. You might want to read it, it explains a lot of stuff about static vs. dynamic libraries. You could also clone the git repository and experiment with the Xcode project included. The part on localization is outdated though (they now compile automagically).

I quickly browsed through this post (it is quite long). From what I read, you should use #ifdef __APPLE__ where needed. As you've already figured out the include for OpenGL are different on OSX. You also shouldn't be using g++. On Lion and Mountain Lion you have clang++ which is the preferred compiler on OS X. Finally, instead of tweaking the makefile (which is a pain unless the team uses CMake) you should try out Xcode and build with that.

Finally a couple of tips for Xcode:
set GNU++98, use libstdc++, remember your library include paths, use macports as much as possible, remember to add your SDL header paths, remember SDLmain.m and .h, make sure your main is the correct format, make sure you delete the main.m created automatically for you, add ../src/** for header search paths. Check out the manaplus xcode project for more stuff, or my ValyriaTear github branch for examples of working with openGL, openAL and GLUT.

Have fun and good luck! Great to see another mac dev
Socapex

[hc]

Sounds like some valueable hints.

Knitter has added the necessary platform entries to the makefile and added a few __APPLE__ for some includes.
Linwarrior's makefile made it rather easy btw I think and it may be that the other compiler didn't support the latest c++0x language features necessary back then.

I'm actually quite proud of Linwarrior's KISS but mighty makefile and I positivly absolutly hate autoconf/automake - usually it only helps in not even being able to start a compilation when a version or directory differs and it takes forever to reevaluate things it evaluated just before
On the other hand those issues may be general compilation issues of those projects and used libraries - who knows.
Besides: autoconf isn't well supported on windows to say the least.

As for cmake: Just good (enduser) experience here so far but I'll stick for now with the makefile - it just works - even multithreaded.
You can have a look at Linwarrior's makefile, I think it's rather short and intuitive where to set platform specific values.

But I don't have a clue if Linwarrior still compiles on mac.
Maybe you could have a test-compile and post your results and possibly suggestions?