[SOLVED] Compile error with Maya 2013

Trying to build with exporter support for Maya 2013, I got this peculiar error:

[ 75%] Building C++ object built/tmp/mayaegg2013_loader.o
g++ -ftemplate-depth-30 -fPIC -c -o built/tmp/mayaegg2013_loader.o -Ibuilt/tmp -Ibuilt/include -I/usr/include/python2.7 -I/usr/include/eigen3 -I/usr/autodesk/maya2013-x64/include -DMAYAVERSION=MAYA2013 -DMAKEPANDA= -Ipandatool/src/mayaegg -Ipandatool/src/maya -pthread -msse2 -ggdb -D_DEBUG pandatool/src/mayaegg/mayaEggLoader.cxx
/usr/autodesk/maya2013-x64/include/maya/MFnTransform.h: In member function ‘MayaEggGroup* MayaEggLoader::MakeGroup(EggGroup*, EggGroup*)’:
/usr/autodesk/maya2013-x64/include/maya/MFnTransform.h:181:2: error: ‘MFnTransform::MFnTransform(const MFnTransform&)’ is private
pandatool/src/mayaegg/mayaEggLoader.cxx:373:60: error: within this context

The error doesn’t happen for Maya 2011 or 2012 during the same build process. MFnTransform.h has not changed in Maya 2013, and the same mayaEggLoader.cxx is being used for both, obviously.

Hmm, but perhaps there is something else different in the headers. Changing -I/usr/autodesk/maya2013-x64/include to point to maya2012-x64/include eliminates the compiler error.

Oh for crying out loud:

http://download.autodesk.com/us/maya/pdfs/2013/maya_2013_release_notes_en.pdf

doesn’t seem to be fixed in service pack 1.

Ok, with a little help from the internets I was able to get workarounds for all the places where this bug gets in the way, and maya2egg2013 works now on Linux. Once I get Maya installed on Mac and Windows I’ll test those too.

Hi benchang, glad to hear you were able to resolve this. Have your workarounds already been committed to cvs?

By the way, found your discussion about this on stackoverflow and was able to make the necessary changes to compile for maya 2013 64 bit.

Interestingly this post seems to indicate that the change to make the MFnBase class copy constructor private was potentially done on purpose:
around-the-corner.typepad.com/ad … ivate.html

However Autodesk’s own release notes do indicate that it’s a bug:
download.autodesk.com/us/maya/pd … tes_en.pdf

No, I should probably look at how to commit changes :slight_smile:

MisterPete, do you have a Win64 build with Maya 2013 you could share? I got it all to build for Linux, but had some trouble installing Maya 2013 in Windows so haven’t finished that build yet.

EDIT: nevermind, I got it to work.

I’m working on a full vs2008sp1 compile of win64 panda3d including as many supported third party libraries as possible. As a starting point I used the thirdparty.zip that David provided in a forum post which includes some but not all libraries precompiled for 64 bit (missing bullet, fftw, openssl, rocket and a few others).

I’ll report back when I’m done.

Hey, we should join forces. I got one built with bullet, but haven’t added rocket yet.

Here’s where I’m storing my builds
phpbb.hass.rpi.edu/viewtopic.php?f=6&t=40

librocket was a bit of a pain as it required building a couple dependencies including boost python and also needed a small change to the source. I’ve got bullet, fftw, squish, openssl, wx, fltk and rocket compiled along with the maya2013 tools.

If you get opencv or artoolkit compiled let me know, those would be the next two.

I’ll put my build up on dropbox soon.

I’ve compiled artoolkit and opencv as well (just have to determine if I actually need to compile an older version of that).

Looks like awesomium won’t be an option quite yet. See here:
support.awesomium.com/discussion … rt-via-ipc

I think that just leaves eigen3, other than support for all max and maya versions.

I recently started doing the same thing, but I’ve been recompiling both the 32-bits and 64-bits libraries so that they are kept in sync. I’ve also started the good habit of putting a file in there describing the software license and compilation notes.
So far I have artoolkit, bullet, fltk, freetype, jpeg, nvidiacg, openssl, png, squish, zlib. Let me know if you want any of them, and I’ll put them up on dropbox.

Which change to the Panda3D source was required to build libRocket? Do you have a patch so that I can commit it?

Hi rdb, sorry about the delay in replying, here are my work arounds

Small change in librocket. I believe this line may have been present in an earlier version of librocket so it wasn’t a problem before even though there is a panda Factory class:

--- Include/Rocket/Core/Decorator.h
+++ Include/Rocket/Core/Decorator.h
@@ -39,6 +39,7 @@
 
 class DecoratorInstancer;
 class Element;
+class Factory;
 class PropertyDictionary;
 class Property;
 struct Texture;

================

Second issue was the following. In boost/python/detail/wrap_python.hpp on line 50 we have “# include <pyconfig.h>” which defines HAVE_LONG_LONG.

However at some point earlier in panda pyconfig.h has already been included and afterwards HAVA_LONG_LONG is undefined.

So when we reach the following on line 197 of wrap_python.hpp, BOOST_PYTHON_LONG does not get defined:

#if defined(HAVE_LONG_LONG)
# if defined(PY_LONG_LONG)
#  define BOOST_PYTHON_LONG_LONG PY_LONG_LONG
# elif defined(LONG_LONG)
#  define BOOST_PYTHON_LONG_LONG LONG_LONG
# else
#  error "HAVE_LONG_LONG defined but not PY_LONG_LONG or LONG_LONG"
# endif
#endif

Then in boost\python\converter\builtin_converters.hpp at line 125 it assumes that BOOST_PYTHON_LONG_LONG has been defined

# if defined(_MSC_VER) && defined(_WIN64) && PY_VERSION_HEX < 0x03000000
/* Under 64-bit Windows std::size_t is "unsigned long long". To avoid
   getting a Python long for each std::size_t the value is checked before
   the conversion. A std::size_t is converted to a simple Python int
   if possible; a Python long appears only if the value is too small or
   too large to fit into a simple int. */
BOOST_PYTHON_TO_PYTHON_BY_VALUE(
    signed BOOST_PYTHON_LONG_LONG,
    (   x < static_cast<signed BOOST_PYTHON_LONG_LONG>(
            (std::numeric_limits<long>::min)())
     || x > static_cast<signed BOOST_PYTHON_LONG_LONG>(
            (std::numeric_limits<long>::max)()))
    ? ::PyLong_FromLongLong(x)
    : ::PyInt_FromLong(static_cast<long>(x)), &PyInt_Type)
BOOST_PYTHON_TO_PYTHON_BY_VALUE(
    unsigned BOOST_PYTHON_LONG_LONG,
    x > static_cast<unsigned BOOST_PYTHON_LONG_LONG>(
      (std::numeric_limits<long>::max)())
    ? ::PyLong_FromUnsignedLongLong(x)
    : ::PyInt_FromLong(static_cast<long>(x)), &PyInt_Type)
//
# elif defined(HAVE_LONG_LONG) // using Python's macro instead of Boost's
                               // - we don't seem to get the config right
                               // all the time.
BOOST_PYTHON_TO_PYTHON_BY_VALUE(signed BOOST_PYTHON_LONG_LONG, ::PyLong_FromLongLong(x), &PyLong_Type)
BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned BOOST_PYTHON_LONG_LONG, ::PyLong_FromUnsignedLongLong(x), &PyLong_Type)
# endif

My fix was just setting BOOST_PYTHON_LONG_LONG

+#if defined(PY_LONG_LONG)
+# define BOOST_PYTHON_LONG_LONG PY_LONG_LONG
+#elif defined(LONG_LONG)
+# define BOOST_PYTHON_LONG_LONG LONG_LONG
+#else
+# error "Neither PY_LONG_LONG nor LONG_LONG defined"
+#endif