After a successful recompile in Vista 64 for 1.5.3, I’m now attempting to get it compiled with 1.6.0.
Currently, I’m only compiling with python. I will add other libs as I get them and roll them over to 64bit.
Also I’m using Visual Studio 2008
This is a documentation of what I had to do:
- Get Python 64. I’m using 2.5.4. I got the .msi for AMD64 architecture from python.org
- Make a copy of all the third party libs sans Pmw (sense it’s python) and store into a sub directory win32 in the thirdparty directory. I also made another directory called win64 and installed python 64 into that directory. Called in win-python.
- Modify the makepanda.py and makepandacore.py. Changes include:
-file to intelligently look into either win32 or win64 directories.
-add the /MACHINE:X64 flag to the linker options intelligently
-get rid of the pandaIcon.obj linking because its not 64 bit compatible
-Make sure downloader isn’t compiled if ZLib isn’t enabled
-Make sure /bigobj flag is used for pgraph_composite obj compiles
- Modify code to work in 64bit.
-express/trueClock.cxx: Changed set_cpu_affinity function to use an explicit cast to PDWORD_PTR
-Modify winDisplay/winGraphicsPipe.cxx to use MSVC Intrinsics instead of assembly instructions. Assembly is not supported on x64.
This gives me a compile of Panda. The next thing I have to do now is fix genPyCode with some arguments.
Sounds useful! Would you like to give us your changes to incorporate in the repository?
Ok, I’ll email it to you. Also I just made some changes to the genPyCode calling section of the makepanda.py It will now not try to use the ode libraries if they are skipped in the configuration.
And could you also send me at least the makepanda modifications and the thirdparty stuff you have so far? Then I can integrate those into the release system.
If I can get myself a copy of WinXP64, I might even be able to put a 64-bits exe on the download page.
Was there anyone at VR that was compiling 64bit libs? I’ve been doing a compile here. I’ve got several of the third party libs updated and compiled but ffmpeg is particulary hard because it doesn’t use MSVC.
Any successes with that?
No, we haven’t compiled with FFMPEG for a while, for just the reason you name. And to my knowledge, no one here is building in Win64. We do build for 64-bit Linux, but we don’t use FFMPEG in that build.
I’ve finally managed to compile a useful version of Panda on windows 64. It has zlib, png, jpeg, ode, fmod, freetype and cg
However, enabling threads on windows 64 may be some work. Context Switching uses some assembly. Why aren’t we using setjmp and longjmp included again?
Panda’s SIMPLE_THREADS implementation requires rolling its own context switch. The ANSI flavor of setjmp/longjmp, though it is not intended for this purpose, can usually be used to implement a context switch, if you happen to know within the saved context where the stack pointer is stored. However, the Windows implementation of setjmp/longjmp cannot be used for this purpose, because that implementation actually checks that you haven’t mangled the stack pointer (!). Thus, to hand-roll context switches on Windows, we have to write our own implementation of setjmp/longjmp in assembly.
If you’re not interesting in writing this assembly code in the Win64 case (and no one would blame you if you weren’t), then I’d recommend simply building with true threads instead of SIMPLE_THREADS.
Hey Dave, nope not against writing assembly. The problem is that MSVC doesn’t support asm for 64bit. That’s why I had to convert some of the windisplay functions to use intrinsics rather than the assembly.
Hmmm context switching the way we’re doing it may be difficult in 64bit windows then…
Really? Weird. I wonder why they would omit this essential, and trivially implemented, feature?
Sounds like it. I believe in the absence of i386 assembly, contextSwitch.c falls back to setjmp/longjmp. Who knows, maybe it works in win64–it might be worth a try. You might have to figure out the location of the stack pointer within the context block empirically (test_setjmp.cxx will be useful for this).
Still, it may not matter that much. The SIMPLE_THREADS implementation of context switching is designed for lightweight threading implementation on uniprocessor machines. On a 64-bit machine, you may not need that lightweight implementation, and you might be likely to be multi-CPU anyway, right? So you might as well use full threading.
I notice that there still isn’t a win-python-x64 in the thirdparty packages on the website, even though the current version of makepanda.bat requires that directory. I tried to build the cvs version of panda the other day and failed so I want to make sure I do everything right this time. Should I get python 64 from python.org? Would copying the provided 32bits version suffice if I just want python for building? (I build with --no-python)
Email me if you want a more complete thirdparty package.
As for python, you could download it from python.org and make a single-user install into thirdparty/win-python-x64/.
I must warn you though- the x64 port is largely untested.