Linux compile Quake
Linux compile Quake
Theres a guy trying to compile the linux version of proquake, for 64bit system. His attempts to compile on the 32bit version works just fine, though when he compiles it on the 64bit system, it gives him a segmentfault on execution. Anyone have experience with linux compiles for Quake?
-
frag.machine
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
This may be useful as a guideline.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC
(LordHavoc)
quite a bit of changes to go in before it runs as a 64 bit executable.
for one ints are not the same size as on 32 bit same goes for unsigned
and its the same problem on windows.
one workaround to the int and unsigned problems is using intptr_t and unintptr_t (not sure if ms has something equivalent but on mingw64 thats mostly the way).
several other things i believe both mh and spike commented on this in some other thread.
for one ints are not the same size as on 32 bit same goes for unsigned
one workaround to the int and unsigned problems is using intptr_t and unintptr_t (not sure if ms has something equivalent but on mingw64 thats mostly the way).
several other things i believe both mh and spike commented on this in some other thread.
Hmm, well im not sure if he needs to compile it for native 64bit, but just to run on a 64bit linux system. I'll look thru that stuff and see if i can compile it on my system then pass him the info...
Thanks for the quick replies, i'll post an update so that others trying to compile the make -unixded can do so without problems.
Thanks for the quick replies, i'll post an update so that others trying to compile the make -unixded can do so without problems.
-
dreadlorde
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
You can run a 32bit executable on a 64bit system, as long as you also have the 32bit libraries that get dynamically loaded.
edit: I noticed you mentioned unixded. iirc, the proquake dedicated server executable is statically linked on linux (like it should be). You might want to ask baker how he managed that, I couldn't figure it out.
edit: I noticed you mentioned unixded. iirc, the proquake dedicated server executable is statically linked on linux (like it should be). You might want to ask baker how he managed that, I couldn't figure it out.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
Hey guys,
I'm the guy R00k mentioned that was trying to get the 32 bit executable to work on a 64 bit machine.
Here's the current deal:
The pre-compiled linux proquake binary (available from quakeone.com/proquake version 3.90) runs fine in both 32 and 64 bit environments.
I successfully compiled the 3.90 source on my 32 bit linux machine as follows:
1. ./configure
2. make unixded
I ended up with a binary, unixded, which works fine under 32 bit
When I copy that binary over to the 64 bit machine, even after chmodding +x, and running ./unixded, it gives me "no such file or directory".
I can compile it under 64 bit with or without cflags set to -m32 but get a "segmentation fault" when I try to run it.
I did some investigation into the matter by running this command on the precompiled working version (downloaded from quakeone.com/proquake):
file pqlinux (where pqlinux is the binary) and it gave me this output:
However, when I run that exact command on *either* the one I compiled on my 32 bit linux machine or the 64 bit machine, I get this:
So that led me to this:
I figured I'd just comiple it on my 32 bit machine with this method:
I ended up with two warnings:
and
So, I thought I would at least try to execute my new static binary.. on the 64 bit machine. It actually RAN, but crashed with this message:
I figure I'm at least getting further along, but I'm not real savvy at compiling static binaries that run on both 32 and 64 bit environments.
Any and all help would be appreciated - this is my very first post.
I'm the guy R00k mentioned that was trying to get the 32 bit executable to work on a 64 bit machine.
Here's the current deal:
The pre-compiled linux proquake binary (available from quakeone.com/proquake version 3.90) runs fine in both 32 and 64 bit environments.
I successfully compiled the 3.90 source on my 32 bit linux machine as follows:
1. ./configure
2. make unixded
I ended up with a binary, unixded, which works fine under 32 bit
When I copy that binary over to the 64 bit machine, even after chmodding +x, and running ./unixded, it gives me "no such file or directory".
I can compile it under 64 bit with or without cflags set to -m32 but get a "segmentation fault" when I try to run it.
I did some investigation into the matter by running this command on the precompiled working version (downloaded from quakeone.com/proquake):
file pqlinux (where pqlinux is the binary) and it gave me this output:
Code: Select all
pqlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.0, not strippedCode: Select all
pqlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, for GNU/Linux 2.6.0, not strippedI figured I'd just comiple it on my 32 bit machine with this method:
Code: Select all
1. ./configure
2. make SHARED=0 CC='gcc -static' unixdedCode: Select all
security.c:43: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
unixded-net_udp.o: In function `UDP_GetAddrFromName':Code: Select all
net_udp.c:430: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linkingSo, I thought I would at least try to execute my new static binary.. on the 64 bit machine. It actually RAN, but crashed with this message:
Code: Select all
EDICT 214:
target r
dmg_take 0.0
Host_Error: PR_ExecuteProgram: NULL function
ERROR: Host_Error: PR_ExecuteProgram: NULL functionI figure I'm at least getting further along, but I'm not real savvy at compiling static binaries that run on both 32 and 64 bit environments.
Any and all help would be appreciated - this is my very first post.
Actually that LAST error is quakeC crappin out, so something isnt working in the engine, on the 64bit level that is corrupting the "unmodified" mod.
did you try adding unixded_LDFLAGS = -static to the makefile?
Actually you dont need the security.c stuff thats just for cheatfree and this wont be certified obviously ;O
did you try adding unixded_LDFLAGS = -static to the makefile?
Actually you dont need the security.c stuff thats just for cheatfree and this wont be certified obviously ;O
The debugger is your friend.Tremor wrote:I can compile it under 64 bit with or without cflags set to -m32 but get a "segmentation fault" when I try to run it.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Ok fellas...
I think I've found the issue..
I grabbed the original source (unmodified with R00k's cullentities code) and did the following:
1. Put unixded_LDFLAGS = -static in Makefile.in
2. ./configure
3. make unixded
4. 'file unixded' - ouput was static, so the makefile.in mod worked
5. Copied my new binary over to the 64 bit machine
Guess what? No crash, no quake c error, no crapout.
So, apparantly compiling standard src works like a champ and the issue was either with R00k's code OR I screwed something up while adding the code..
hooray for the compile!
I think I've found the issue..
I grabbed the original source (unmodified with R00k's cullentities code) and did the following:
1. Put unixded_LDFLAGS = -static in Makefile.in
2. ./configure
3. make unixded
4. 'file unixded' - ouput was static, so the makefile.in mod worked
5. Copied my new binary over to the 64 bit machine
Guess what? No crash, no quake c error, no crapout.
So, apparantly compiling standard src works like a champ and the issue was either with R00k's code OR I screwed something up while adding the code..
hooray for the compile!