Quote:
Originally Posted by Bulle
It would be unfair to say it is poor programming not to have "natural" 64-bits support. 64-bits support when programming on a 32-bits platform has to be seriously planned in advance, and even then it requires corrections once you switch to the actual 64-bits platform. It is an outstanding effort to support both, C is like that, close to the "machine". If you want hardware indepence, use Java or something else. EQEmu is in C, we have to live with that.
|
Especially when you consider that development started on this before 64bit microprocessors were available to most people.
Quote:
Problems do not only occur when casting values, but for example when reading binary data from files (ints are not the same size). Cross-processor compatibility support (like in PowerPC vs Intel) could mitigate this problem, but EQEmu on Mac is not really something I have heard of. We have to live with that too !
That said, I will answer the question of gaeorn :
The surefire way to ensure you do not alter 32-bits code when adding changes for 64-bits support is to use #defines. Everytime you need to replace an existing portion of code with your new code you use something like this :
Code:
#ifdef __64_bits__
<your new code>
#else /* __64_bits__ */
<the old code>
#endif /* __64_bits__ */
The comments are there for readability (especially if you have tens of lines of code in there), and cost nothing.
Obviously you also have to #define the __64_bits__ macro somewhere when you are on a 64-bits plaform. It can be done on the compile-line with a -D__64_bits__ flag (read : your Makefile). There could be an existing flag for your compile platform but I cannot remember it off-hand. If it exists then just use it instead of my made-up macro.
|
Yeah, I know about #ifdef. I just was hoping to keep that to a minimum. I'm sure many parts of the code could be written in a way to run happily on both 32bit and 64bit. Only a handful will likely require wrapping with #ifdef blocks for the two architectures.
But, if the developers would prefer me to do all of it as #ifdef blocks, I can. Perhaps KLS or another developer can chime in with their preference.
Quote:
I can remember trying to compile EQEmu for 64-bits a year ago (and succeeding), but running the executables failed miserably with a segmentation fault. Not a surprise really, as the code is not meant to support it. Be warned this can be very tough to fix.
|
I ran into the same problem. Found it and resolved it. I've done enough changes to my 64bit version that it is very playable in my testing. However, it doesn't have a user population to truly test out everything.
Quote:
One hint : on a 64-bits Linux platform you can always create a chroot 32-bits installation to run your programs with everything 32-bits. That is how I use EQEmu on my (native 64-bits) server. The details vary depending on your distribution, I am on Gentoo and they provide a nice "how-to" on how to create the 32-bits chroot environment. Just know that you will need as much HD space as you use on your main Linux root to support it. Yes, it works fine.
Good luck
|
I use Fedora and it will very cleanly run 32bit binaries without a chroot. Fedora has split out the library paths to /lib and /lib64 (same for others like /usr/lib). The problem is it doesn't make a clean build environment for 32bit. But I have built a 32bit version on a system I have at work. It ran fine, but was noticeably slower performance, much more so than I would have expected. So I prefer to stick with 64bit and fix it. Besides, its the "right" way to do it, lol.