>> First, let me just state that cross-compiling a 32 bit binary on a 64 >> bit FreeBSD system is currently not "supported" (for pretty much any >> 3rd party software such as ioquake3). > > Actually this is not true, if the required 32bit libraries are around > it will work, both with a direct gmake call or from the ports tree.
No, it's broken. I have /usr/lib32/ installed just fine. I can run a 32 bit binary just fine (e.g. ioq3ded.i386). I just can't compile one. I imagine it's easy to compile a 32 bit binary in a jail, but that's a different story. [Actually I'm working on a jail now.] Even after adding something like "-B/usr/lib32" or "-L/usr/lib32" to get the link stage to work, it _will_ compile without errors but won't run correctly because of incorrect data sizes etc. that are defined in header files. Like I said, jail will probably cross compile fine. There's some amount of discussion regarding the inability to cross compile 32 bit apps on 64 bit FreeBSD, but here's one: http://forum.nginx.org/read.php?23,119497,119956 Apparently it might work in -CURRENT at this point but definitely won't work in STABLE-8. The issue is with header files that define data sizes etc. ===================== ... <64 bit slow> > Umm... the difference never seemed very significant for me (note, I > consider it significatn, just not VERY significant). I think it's just > the pointer conversion vm code. You can use native libraries to > circumvent this. Regarding 64 bit servers. Have you tried running a 64 bit ioq3ded? It's twice as slow, consumes twice as much CPU. You won't notice any difference in the client because only a small percentage of the CPU is needed for the VM stuff in the client. On the server it's a whole different story. _______________________________________________ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
