GL dylib will not load on custom OSX runtime build

Compiling or Editing the Panda Source
1

I have a problem where Panda’s GL library is not loading on OSX (and resulting in my program terminating due to no display method available). This is the warning shown (path where program resides replaced with “blah”):

:display(warning): Unable to load: dlopen(/blah/panda3d/spacebullet_1.9/osx_i386/libpandagl.dylib, 10): Symbol not found: __Z13_dcast_verify10TypeHandlemPK11TypedObject
Referenced from: /blah/panda3d/spacebullet_1.9/osx_i386/libpandagl.dylib
Expected in: /blah/panda3d/spacebullet_1.9/osx_i386/libpandaexpress.dylib
in /blah/panda3d/spacebullet_1.9/osx_i386/libpandagl.dylib

This is on a custom build of Panda generated with:

export VERSIONER_PYTHON_PREFER_32_BIT=yes
python makepanda/makepanda.py --nothing --optimize 4 --rtdist --distributor spacebullet --host file:///work/panda3d/built_spacebullet/stage/ --p3dsuffix spacebullet --use-deploytools --use-openssl --use-direct --use-fmodex --use-wx --use-jpeg --use-png --use-python --use-zlib --use-gl --use-bullet --use-eigen --use-steam --arch i386 --use-cocoa --threads 2

I am generating a standalone executable with the following:

panda3d ../panda3d/built_spacebullet/stage/pdeployspacebullet.p3d -t host_dir=. -t verify_contents=never -v 1.1 -P osx_i386 blah.p3d standalone

Running the Python script directly works just fine on a SDK built and installed with:

export VERSIONER_PYTHON_PREFER_32_BIT=yes
python makepanda/makepanda.py --nothing --installer --optimize 3 --use-direct --use-pandatool --use-fmodex --use-png --use-python --use-zlib --use-gl --use-bullet --use-eigen --use-steam --arch i386 --use-cocoa --threads 2 --outputdir built_tune

So I’m pretty sure the problem is with the build (or the executable) and not the actual game code.
I’ve tried doing a full clean build of both my development and release Panda builds but the problem persists.
Any idea how to get my game running?

2

Are you sure there’s no other build on your system that may be conflicting? This particular symbol is only defined at optimize level 3 and not at optimize level 4, so it would seem that perhaps it’s picking the wrong dtool_config.h or a library that’s compiled with the wrong one.

In particular, it looks as though the libpandagl library that got loaded was compiled with optimize 3, whereas the libraries it links with are compiled with optimize 4.

3

Is there a way to query a file to know which one is which?

Update:
Upon closer inspection, my release build appears to have not built a libpandagl.dylib, and the size is the same as the one from the development build. I am guessing it somehow decided to grab the file out of the development build instead.
So really the problem now is finding out why libpandagl.dylib is not being built in the release configuration.

Update 2:
After doing a clean build, it is still not generating libpandagl.dylib. There are no complaints about anything missing except at the very end: :stuck_out_tongue:ackager(warning): No such file: libpandagl.dylib
Maybe it doesn’t think it is required? I do have “–use-gl” specified though. Is there some way I can force it to be built?

4

makepanda.py should print warnings at the beginning (the first few lines after you run it) relating to missing packages. But there should not be a problem building libpandagl on OSX since the system provides the GL headers.

Is there no libpandagl.so either, out of curiosity?

5

I’ve got a p3glgsg_glgsg.o and p3glgsg_config_glgsg.o in the tmp folder, but that’s all the GL-related files I could find in the build. I paid special attention to the output when building, but there were no complaints of any missing files except the one at the end when packing up (this is probably when it’s looking for the library specified in the pdef).

6

Oh, I forgot to mention: on OS X, you have to compile with either Cocoa or Carbon support in order to get a GL renderer. Carbon is the old display API in OS X, but it is only available in 32-bits OS X. Our new renderer uses Cocoa which should work in all versions, though it’s still a bit experimental (but has a few more features than the old renderer as well).

7

Yep, I’ve got --use-cocoa in there, but still no GL lib.

8

Well, I’m stumped. The compilation finishes? There really aren’t any warnings at the beginning of the makepanda output whatsoever? You’re not accidentally specifying “–runtime”? You’re really building with a Python version where sys.platform is “darwin”?

Check whether HAVE_GL and HAVE_COCOA are defined in built/include/dtool_config.h .

9

in dtool_config.h I’ve got “#define HAVE_GL 1”, but “#undef HAVE_COCOA” so that seems to be the problem. I am building with “–rtdist” is that the same as runtime? Can I not do that?

10

Oh, sorry. We don’t support Cocoa in the rtdist build yet, since the plugin hasn’t been ported to Cocoa yet due to some difficulties. You’ll have to build with --no-cocoa --use-carbon for now.

Sorry, I should have realised earlier that this was the problem.

11

Is it possible to force it somehow? I’m using cocoa specifically because of some mouse issues I was having with carbon.
I don’t use the plugin, just standalone executables. I would be perfectly fine with a resulting build that I could use only in that context.

12

A pdeployed executable is basically a copy of the runtime with the .p3d archive embedded within the executable data. So, with pdeploy, there is no avoiding the runtime.

Now, when talking about the issues with porting the runtime to Cocoa, I’ve mostly been thinking about the web plugin. Maybe it’ll be possible to get it working for the standalone use without many hacks, especially since it does not need to run in embedded window mode.

You could start by commenting out this specific line in makepanda.py:

        # We don't support Cocoa in the runtime yet.
        PkgDisable("COCOA")

and then seeing what sort of issues you run into.

You do not need --use-carbon. You should make a 32-bit build and not a 64-bit build.

13

Everything seems to work just fine after commenting out the lines in makepanda.
Thanks for the assistance!