Mayaegg: undefined reference to std::basic_ostream

Hi,

I’m getting some weird errors when trying to compile Panda3D with Maya support:
pastebin.ubuntu.com/68764/
Am running 64-bits ubuntu, using Makepanda as build system.

I found this note in Config.pp:

// Also, as of Maya 5.0 it seems the Maya library will not compile
// properly with optimize level 4 set (we get link errors with ostream).

Although, I believe makepanda’s default optimize level is -O2. Since I’m also using Maya 2008 this seems not relevant anymore.

Did I forget to add some link lines or so? This is really confusing me.

Thanks in advance,
pro-rsoft

Hmm, I’m not sure. Many years ago, we had problems with Maya and ostream, because of the C++ transition from the old iostream implemention in <iostream.h>, to the new one in . Basically, these two implementations were incompatible with each other at the compiled binary level, and within any given application, all of the code had to use the same interface. Maya was slow to make the transition, and we put some clever #include tricks to work around this. You can see that happening in pandatool/src/maya/pre_maya_include.h and post_maya_include.h.

By now they’ve made that transition (and, in fact, basic_ostream is the name of the new implementation), so we don’t need those sneaky #include tricks. But it’s important to #define the right symbols to turn off this behavior in pre_maya_include.h. Make sure you’re not defining MAYA_PRE_5_0, and make sure you are defining HAVE_IOSTREAM.

This is just an opening guess. The actual problem might not be related to this at all, but you can start here to try to research it.

David

Thanks for the detailed info. I’ve triple-checked, but HAVE_IOSTREAM is defined correctly and MAYA_PRE_5_0 is undefined. I even verified that by putting #error things in pre_maya_include.h.
I’ve also tried defining MAYA_PRE_5_0 but this of course doesn’t work at all.

In Maya’s lib/ dir, however, I found it’s own copy of libstdc++.so, but it’s 6.0.8 which is quite recent. I nm’ed it to be sure but it does indeed contain basic_ostream stuff.

Wow, that sounds like trouble. What happens if you temporarily rename that file?

David

I did already try that, but then got all kinds of other linker errors, like:

built/lib/libmayaegg2008.a(mayaegg2008_composite1.o): In function `MayaBlendDesc::~MayaBlendDesc()':
mayaegg_composite1.cxx:(.text+0xad6): undefined reference to `MFnBlendShapeDeformer::~MFnBlendShapeDeformer()'

and alot more of those. It seems normal for Maya to have its own libstdc++ libs in the lib/ dir. Besides, the one shipped by maya is 6.0.8 while my system version is 6.0.9, so it’s not like there is much of a version difference.

No, see, look back at your pastebin–you were getting those same errors, too, in the first pass, but you didn’t notice them in all the noise about ostream. So, renaming the libstdc++ library had the effect of solving the ostream errors, leaving only these Blend errors.

The Blend errors are no doubt due to some particular Maya library not being included on the link line. There are a bunch of different Maya libraries, and the exact set you need to include changes from one version to the next, and even changes between Windows and Linux. It shouldn’t be too hard to figure out which library includes the needed symbols, though.

David

Thanks a bunch! There was just one maya library I forgot to link to.
That still left me lots of linker errors, but they went away when I also moved the libgcc_s.so.

Now, how should we fix this? We can’t expect users to remove the library files from their maya installation before using panda, can we? Is there some way to tell g++ not to load several libraries? I know it’s possible on OSX, but also on Linux?

I don’t know. Maybe if we just rearranged LD_LIBRARY_PATH to ensure that /lib and /usr/lib are first on the path? Or /lib64 and /usr/lib64, as the case may be?

We’re already munging LD_LIBRARY_PATH to put the Maya stuff there. We just have to be sure that it ends up following the system path. Check pandatool/src/mayaprogs/mayaWrapper.cxx (for makepanda) and mayapath.cxx (for ppremake).

There are two different programs that do more-or-less the same thing, because Josh and I both solved the same problem independently. Josh wrote mayaWrapper and integrated it with makepanda, and I write mayapath and integrated it with ppremake. Though, come to think of it, I don’t know if Josh ever made mayaWrapper work with non-Windows.

David

Thanks. Well, makepanda does nothing with the LD_LIBRARY_PATH at all. I’m going to further investigate how to exclude several library files. On OSX, there is -dylib_file but I haven’t seen an equivalent for linux yet.

I noticed mayaWrapper.cxx, yes, but it’s only for windows.
I’ll try to port it to Linux and OSX as well, based on mayapath.cxx.

By the way, there seems to be an error in mayapath.cxx when compiling for linux:

  // Also put the Maya bin directory on the PATH.
  Filename bin = Filename(maya_location, "bin");
  if (bin.is_directory()) {
    char *path = getenv("PATH");

and a bit down:

  // Linux (or other non-Windows OS) gets it added to LD_LIBRARY_PATH.
  Filename bin = Filename(maya_location, "bin");
  if (bin.is_directory()) {
    char *path = getenv("LD_LIBRARY_PATH");
    if (path == NULL) {
      path = "";
    }

So, that’s a redefinition of “Filename bin”, which the compiler doesn’t like. I didn’t fix it since I don’t know exactly what it’s supposed to do there.

Ah, thank you. Hmm, yes, that points out that mayapath.cxx is actually as yet untested on Linux and OSX, since I don’t have a Maya installation on those platforms to test it with.

I checked in a fix to the problem with "Filename bin’.

David