Missing symbol with mac runtime build [FIXED]

Scripting Issues
1

When running my mac build from a p3d, I get “Symbol not found: __ZN10TypeHandle16dec_memory_usageENS_11MemoryClassEi” when importing a python extension module that links against panda. (Its written in Cython)

I stripped the Cython code for the module down to the minimum:

cdef extern from "geomVertexWriter.h":
    cdef cppclass GeomVertexWriter:
        void add_data1f (float x)

def x():
    cdef GeomVertexWriter* w=<GeomVertexWriter*><long>0
    w.add_data1f(0)

It works fine when running for source as long as I force panda to load libpanda

import panda3d
libs=['libpanda']
for lib in libs: panda3d.__manager__.libimport(lib)

makes the source build work, but panda3d.manager does not exist in the runtime build apparently.

from panda3d.core import GeomVertexWriter

also makes running form source work, and does not cause an error in the runtime build, but I still get the missing symbol error.

If I don’t do one of these things to make libpanda load when running form source I get a different missing symbol: __ZTI11TypedObject

Any suggestions for how to fix/debug this? Windows builds work fine.
Panda3D 1.7.0

2

I found that Cython and p3d did not work together very well. My particular case was on ubuntu though. When cython compiles its tied to the interpreter you have now. If your interpreter is different (even some compile flags) then from the one that was used to build panda3d runtime you get errors.

Check what interpreter you have in your runtime install and make sure to compile an interpreter to match down to the compile flags. Once you get to C++ realm nothing works together well.

3

Its an issue linking against panda, not an issue linking against python. Without linking against panda itself, it works fine on Mac and Windows, and I haven’t tried a p3d build on linux recently.

Is there a list of the compile flags used to build the panda3d runtime on mac? Is there a way to force the runtime to load all it’s libraries? (panda3d.manager does not appear to exist in the runtime)

4

Now that I think of it, the runtime distribution is indeed built differently than the SDK build. Most importantly, it is compiled with OPTIMIZE 4, and possibly other definitions. Perhaps that could be making the difference here.

You could try downloading the panda3d rtdist package manually, extracting the multifile and linking to those libraries instead.

5

I’m back and trying this again on panda 1.8.0 now that WxPandaWindow has resolved my other outstanding mac problem (Thanks to whom ever worked on that!)

I downloaded panda3d.cmu_1.8.osx_i386.mf.1.pz from runtime.panda3d.org/panda3d/cmu_1.8/osx_i386/

An unpacked it into a directory, and specified that directory in ‘library_dirs’. Normally on mac I don’t actually set library_dirs, and setting it did not seem to change anything (still runs fine outside a p3d, and still gets the same link error inside one)

Full error:

Any other suggestions for what to try?

If not, I’ll try and work toward a minimal example project with the problem.

6

Then the wrong libraries must have been picked up. You might be able to verify that with otool -L.

7

I ran otool -L on my .so and it shows:

And as mentioned before, it does not seem to need (or use) a library_dirs list. I don’t think its doing anything with the binaries, its working purely off the headers.

I’ve prepared a minimal example, complete with a C++ python extension module that links against panda, a build script to compile it on mac and produce a p3d file that gets the link error. Run main.py (after compiling) and it links correctly. Run the produced p3d, and it fails.

Complete setup, including all scripts, object files and binary files and the p3d: http://craig.p3dp.com/ProjectZips/LinkTest.zip
For easy viewing, there is an unzipped copy browse-able here: http://craig.p3dp.com/ProjectZips/LinkTest/

Hopefully this will provide some insight!

8

With rdb’s help, I made a little progress. (Thanks!)

Using this to build:

It now at least claims to link to panda, and I don’t need silly import tricks to convince it to load panda’s dlls. This is great, and removes a ugly work around I was using, but does not fix the issue at hand. I still get the same missing symbol error when running with the runtime, and it still works fine with the SDK build.

I think I might need some more precise settings for the command line flags exactly matching those used to build the runtime, and/or any header files that differ for the runtime.

9

As I pointed out earlier, linking to the “panda” library is not enough. You need to link to all the libraries that you use, including p3dtool, p3dtoolutil and pandaexpress.

10

I included every lib of the form lib*.dylib included with the runtime.

I still appear to be missing the following symbols:


  "TypeHandle::dec_memory_usage(TypeHandle::MemoryClass, int)", referenced from:
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
  "MemoryUsage::get_global_ptr()", referenced from:
      PointerToBase<GeomVertexArrayDataHandle>::update_type(GeomVertexArrayDataHandle*)in ctest.o
      PointerToBase<GeomVertexData>::update_type(GeomVertexData*)in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o
      GeomVertexWriter::inc_add_pointer()       in ctest.o



  "MemoryUsage::ns_update_type(ReferenceCount*, TypeHandle)", referenced from:
      PointerToBase<GeomVertexArrayDataHandle>::update_type(GeomVertexArrayDataHandle*)in ctest.o
      PointerToBase<GeomVertexData>::update_type(GeomVertexData*)in ctest.o

I got this list by omitting the “-undefined dynamic_lookup”, and stripping out all the python related errors (which it does seem to dynamically find correctly).

Now my link command is this mess (I’ll may clean this up later):


c++ -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -bundle ./ctest.o -L$runtimeBinPath    -lavcodec.52.43.0 -lp3dtoolconfig -lavformat.52.44.0 -lp3glstuff -lavutil.50.7.0 -lp3tinydisplay -lbz2.1.0 -lpanda -lcrypto.0.9.7 -lpandaexpress -lfftw.2.0.7 -lpandafx -lfreetype.6 -lpandagl -lgcc_s.1 -lpandaphysics -lncursesw.5 -lrfftw.2.0.7 -lp3direct -lssl.0.9.7 -lp3dpython -lswscale.0.7.2 -lp3dtool -lz.1    -o ./ctest.so

So after a bit of poking, it seems DO_MEMORY_USAGE in dtool_config.h was the issue. FIXED!

Side note: did you leave DO_MEMORY_USAGE on in the windows runtime, since it works fine?

So everything works now. Fantastic!

To simplify this in the future, can we publish the configurations and flags the runtimes were built with? I may run into other settings that differ, and would like to avoid reverse engineering the config again (though this time was a good learning experience).

I’d be happy to clean up and document my test app to serve as an example for how to build and package C++/Cython code in P3D files.

Thanks again for all your help! Now it works, and a learned a lot :slight_smile: