How to compile 64-bit panda on Windows 7?

I’m moving my question over here from the Pipeline forum, my reason for doing this is that I need to build a version of maya2egg2012 that will work with 64-bit Maya on Windows.

  1. What visual studio version to use? 2008 seems to be the standard for building panda, but can I do the 64 bit build with Express or do I need Pro?

  2. Is there a flag to enable a 64 bit build?

  3. Do I have to edit makepanda.py and makepandacore.py?

thanks!

If you run makepanda with a 64-bit Python, it will build a 64-bit Panda. You should probably start with the source from CVS, rather than 1.7.2, since 64-bit support has improved since 1.7.2.

You can use either 2008 or 2010 to build Panda, but you have to use the same compiler with any thirdparty tools you want to use (especially those with a C++, rather than C, interface). I’m not sure whether the Express version of either one supports 64-bit compilations, but if it does, that will be fine. Some tools may be more dependent on the compiler than others; I’m not sure how Maya fits into this picture. Note that you’ll also need 64-bit builds of any of the thirdparty tools you want to use.

If all you want is maya2egg, then the thirdparty tools (other than Maya) don’t matter nearly as much, of course. You can even omit Python and the build is much faster.

David

I’m not sure if it’ll work, and if 64-bits support is enabled by default. You should try it though, otherwise try changing around some stuff.

Be sure to have a 64-bits copy of Python and of the thirdparty packages!

I build 64-bits Panda on Windows this way every day.

David

Ahah. Yes, I only need to build maya2egg. so if i understand correctly, these are the steps

  1. install 64-bit python (2.7.2-amd64)

do I just do a normal install or should it be installed into the thirdparty directory?

  1. which console do you start makepanda from - the regular command line, Visual Studio 2008 Command Prompt, VS2008 x64 Cross-Tools Command Prompt, or VS2008 x64 Win64 Command Prompt? I figured it should be the latter…

  2. makepanda\makepanda.bat --nothing --no-python --use-maya2012

any other flags I should put in there?

You seem to have a pretty good grasp on the steps. Why not try it? :slight_smile:

  1. I don’t know what you mean. Normally you copy the thirdparty directory into the panda3d directory. But there won’t be any point to doing that in your case, unless you want to build some 64-bit thirdparty tools.

  2. I don’t think it matters. Makepanda should be able to find the compiler. But to help it out, it wouldn’t hurt to start from the VS2008 x64 Win64 command prompt.

  3. Sounds like a good place to start.

David

Thanks, everything seems to work. It all got a lot easier once I got an actual machine with windows on it and stopped trying to do everything in a virtualbox without enough HD space.

I am trying to get this going with 1.8.1 using CPython 3.3-x64, and makepanda is generating x86 executables in both the x86 and x64 visual studio command prompts. Anything else to try?

This wasn’t working because I had not yet copied the thirdparty zip. Apparently makepanda does a conditional on the existence of the x64 folders existing…

Using that zip file from a clean set of folders yields: fatal error C1900: Il mismatch between ‘P1’ version '20081201’and ‘P2’ version ‘20080116’

I expect there is a compiler version issue happening? We are using 2008 sp1.

I’ve seen that happen too, and yes, it’s a compiler version mismatch. One or more of the thirdparty libraries was compiled with a different version of the compiler than yours.

You can try excluding them one at a time to find the culprit(s).

David

Cool, I will just track down a suite of thirdparty libs to use then.

For the record, we don’t support Python 3.3 yet. You’ll have to choose a Python version from the 2.x series for now.

Yeah, I just nabbed the python out of another thirdparty.zip for x64 that is floating around the forum, and that worked fine. Also, I am targetting vs2012/x64, so I ended up just commenting out the manifest handling for VC90’s CRT… which I assume will just use the default manifest entries that expect the redist to be installed on any client that wants to run panda.

Another question: is there scripting floating around for building out thirdparty libs? It looks like quite a few of these libs have files in specific folders that makepanda expects, and many of the libs have special names (like libpandazlib1.lib). Is there automation for handling these things, or do folks that build thirdparty just use cmake and just rename stuff by hand to what makepanda expects?

If there isn’t, I might just whip up a premake script to build things from source zips to the properly named zip files.

Btw: panda3d 1.8.1 (with cg only) compiles without error in debug and release in vs2012 update 3.

So… good progress in building new thirdparty libs from source (using premake). However, I have hit a significant snag:

squish.lib(squish.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(squish.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(colourset.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(colourset.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(colourfit.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(colourfit.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(rangefit.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(rangefit.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(clusterfit.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(clusterfit.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(colourblock.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(colourblock.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(alpha.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(alpha.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(singlecolourfit.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(singlecolourfit.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj
squish.lib(maths.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in panda_panda.obj
squish.lib(maths.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in panda_panda.obj

squish makes internal use of the STL, and as far as I can tell makepanda only looks for a single thirdparty lib file to link into both debug (–optimize 1) and release (–optimize 4) builds of panda. This coupled with the new vs2010/vs2012 #pragma detect_mismatch usage for stl iterator debugging (and /MD vs. /MDd usage) means that different thirdparty lib files need to be linked depending on panda’s optimization level. From what I can tell Microsoft no longer allows one to mix release and debug CRTs in the same process.

So my question is: is it currently possible to link a different third party lib file based on the optimize level (Microsoft CRT version). If not, what would be a good way of doing that? We really don’t want to chuck our debug build out the window as its really handy for detecting memory leaks and heap corruption.

Perhaps then it would be a good idea to have a separate squish_d.lib library that makepanda links to in the case of a debug build?

That is what I was asking how to do. Can makepanda.py currently do that? Until it supports this, we are going to have to build the correct thirdparty libs from source every time we build panda3d. So, when we build debug panda3d we have to clean and build debug thirdpary libs, and when building release panda3d clean and build release thirdparty libs. Another option might be to have separate debug and release thirdpary folders that get passed into makepanda, but this would duplicate the header files in the repo.

Not at the moment, but it’s a matter of a simple “if” check.

Here is the thirdparty build setup I made to get panda3d going with vs2012/x64:

github.com/gorlak/panda3d-thirdparty

It builds most open source libs from scratch (only Cg and ffmpeg are pre-built, I think).

Note: to get this fully working you still need to hack out the mt.exe (manifest settings) build step in makepanda(core).py. I wasn’t sure what a good condition to check to for to conditionally perform it. At the moment our makepanda is pretty hacked up due to other unrelated things, so its not worth sharing at the moment.