Pages: [1]
  Print  
Author Topic: Compiling with OSX  (Read 4326 times)
riotmod
Nub


Cakes 1
Posts: 15


« on: December 09, 2012, 11:35:39 pm »

I just downloaded the 0.8.8 game logic source code (QVMs), and when I tried to compile it, I got this error:

Code:
code/cgame/cg_main.c:1: error: CPU you selected does not support x86-64 instruction set
code/cgame/cg_main.c:1: error: CPU you selected does not support x86-64 instruction set
code/cgame/cg_main.c:1: error: -mstackrealign not supported in the 64bit mode
make[2]: *** [build/release-darwin-i386/baseq3/cgame/cg_main.o] Error 1
make[1]: *** [targets] Error 2
make: *** [release] Error 2

Anybody else having any luck compiling on OSX?  Am I doing something wrong?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1651


Open Arena Developer


WWW
« Reply #1 on: December 10, 2012, 04:52:43 am »

Create a file named "Makefile.local" next to "Makefile" and add "BUILD_GAME_SO = 0" in that file.
Logged

There are nothing offending in my posts.
riotmod
Nub


Cakes 1
Posts: 15


« Reply #2 on: December 10, 2012, 03:28:08 pm »

I did that, and now I get a new error:

Code:
In file included from code/tools/lcc/etc/bytecode.c:5:
code/tools/lcc/etc/../../../qcommon/q_platform.h:301:2: error: #error "Architecture not supported"
code/tools/lcc/etc/../../../qcommon/q_platform.h:352:2: error: #error "Endianness not defined"
make[2]: *** [build/release-darwin-i386/tools/etc/bytecode.o] Error 1
make[1]: *** [targets] Error 2
make: *** [release] Error 2
Logged
xk0rE8r
Ok i've posted twice!


Cakes 0
Posts: 2


« Reply #3 on: December 11, 2012, 07:29:31 am »

I did that, and now I get a new error:
Code:
code/tools/lcc/etc/../../../qcommon/q_platform.h:301:2: error: #error "Architecture not supported"
code/tools/lcc/etc/../../../qcommon/q_platform.h:352:2: error: #error "Endianness not defined"

I went through the same thing yesterday. What helps is that the error points right to the file in question. So I opened q_platform.h and added a few lines for my system. It's pretty basic, just says that your architecture exists, and what kind of math it uses. I typed something out which worked, but copied it over with a bit from the ioquake3 version I have on hand:

Code:
#elif defined __x86_64__
#define ARCH_STRING "x86_64"
#define Q3_LITTLE_ENDIAN

This goes in the Mac OS X section of the file, I just put it on the next line after the section for i386. Intel are always little endian, and PPC big endian
« Last Edit: December 12, 2012, 10:55:31 pm by xk0rE8r » Logged
xk0rE8r
Ok i've posted twice!


Cakes 0
Posts: 2


« Reply #4 on: December 11, 2012, 08:04:27 am »

Other things I noticed when compiling. I got some errors about i386 not being viable for my system and the libraries I have installed, so I added this bit to force it to compile just for this system:

Code:
ifeq ($(PLATFORM),darwin)
    ARCH=X86_64

I should mention that I preferred to have it done UNIX/BSD style so I was use using "make" instead of the universal binary script with the app wrapper. This is because I prefer to manage my folders hand-on, instead of many different ID/IO/OA versions I am mucking about with reading and writing the same folders in Applications Support. Most people probably don't want to bother doing it this way, but my cfg scripts were getting overwritten before.

Biggest problem I had was that SDL 1.2.15 was causing weird compilation errors. It was saying that _main was undefined and something about the library not being X86_64 compatible, which was nonsense. It was compiled from source on this system also, and when I typed: tool libSDL-1.2.0.dylib, it said libSDL-1.2.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64. Searching on the web I saw that many people have had this problem, particularly on 64-bit Snow Leopard systems. What sorted it out for me was that I replaced it with SDL version 1.2.14. For 1.2.14 they had supposedly fixed the problem, but then it recurred in the very next release.

Just remembered, I also needed to put this after the _CFLAGs in the make file. I don't know if it's needed for all of them, the MAP_ANONYMOUS error popped up for server vm:
Code:
-DMAP_ANONYMOUS=MAP_ANON

That about did it, as I recall. I am a noob, so it took me a while to figure out. Seems to  work nicely! I tried using SVN for paks with the latest assets in them, but there are some maps and sounds missing. So I look forward to trying my new binaries today with the release paks. Guess I'll make separate launch scripts for baseoa and baseoasvn
.


Logged
riotmod
Nub


Cakes 1
Posts: 15


« Reply #5 on: December 11, 2012, 11:29:56 pm »

Thanks so much for the help!  This works great!  No more running Ubuntu in a VM...this'll make developing for OA a lot easier for me.

Should we try to get this merged into the main source?  This seems like a pretty simple fix...
Logged
riotmod
Nub


Cakes 1
Posts: 15


« Reply #6 on: August 12, 2013, 10:16:37 pm »

Did these ever get merged?  I hope it did...it makes compiling in OSX so much easier...
Logged
Pages: [1]
  Print  
 
Jump to: