Any one up for OSX work.


I also tried compiling Panda3D on OSX 10.5 and used some slightly different approach.

I used edalytical’s guide as starting point and all these additonal steps are necessary use his guide to compile Panda3D on Leopard.

  1. Config.pp
    In the Config.pp, TAR_IPATH and TAR_LPATH need to removed. Tar support runs into an error with interrogate I couldn’t fix and resorted to disabling tar support.

  2. dtool/pptempl/Global.pp
    interrogate went over lots of header in /usr/include and choked on many of them, especially _structs.h. I noticed that interrogate gets called with -S/usr/include and removing that option kept it from trying to parse the system headers. The option is hard-coded in the Global.pp on line 751.
    Changed the lin to:

#defer interrogate_ipath $[install_parser_inc_dir:%=-S%] $[target_ipath:%=-I%]

Panda and the python libararies compiled fine without this option but I’m not sure if some of the following problems are caused by this removal.

  1. panda/src/nativenet/socket_fdset.h
    I had to change line 39 to:
mutable fd_set _the_set;

Now, I thought the line was “const fd_set _the_set;” but in my current fresh CVS checkout it reads “fd_set _the_set;” so I dont’ know if this got fixed already.

  1. panda/src/nativenet/socket_portable.h
    interrogate couldn’t find some definitions used in socket_portable.h so I had to add them. fd_set and fd_mask actually get defined fine on compilation and wrapping the definitions in a #ifndef made both interrogate and the compiler happy. sockaddr_in gets defined in socket_adress.h but that doesn’t seem to get picked up in socket_portable.h for some reason…
    Add following lines after line 265 “#include <unistd.h>”:
typedef struct sockaddr_in AddressType;

#ifndef _FD_SET
typedef long fd_mask;
typedef struct fd_set {
	fd_mask fds_bits[howmany(FD_SETSIZE, NFDBITS)];
} fd_set;
  1. panda/glstuff/glGraphicsStateGuardian_src.h
    There were some more definitions needed in glGraphicsStateGuardian_src.h and I added them following Hypnos’ instructions after line 83:
typedef void (APIENTRYP PFNGLWEIGHTPOINTERARBPROC) (GLint size, GLenum type, GLsizei stride, const GLvoid *pointer);
typedef void (APIENTRYP PFNGLWEIGHTFVARBPROC) (GLint size, const GLfloat *weights);
typedef GLboolean (APIENTRYP PFNGLISRENDERBUFFEREXTPROC) (GLuint renderbuffer);
typedef void (APIENTRYP PFNGLBINDRENDERBUFFEREXTPROC) (GLenum target, GLuint renderbuffer);
typedef void (APIENTRYP PFNGLDELETERENDERBUFFERSEXTPROC) (GLsizei n, const GLuint *renderbuffers);
typedef void (APIENTRYP PFNGLGENRENDERBUFFERSEXTPROC) (GLsizei n, GLuint *renderbuffers);
typedef void (APIENTRYP PFNGLRENDERBUFFERSTORAGEEXTPROC) (GLenum target, GLenum internalformat, GLsizei width, GLsizei height);
typedef void (APIENTRYP PFNGLGETRENDERBUFFERPARAMETERIVEXTPROC) (GLenum target, GLenum pname, GLint *params);
typedef GLboolean (APIENTRYP PFNGLISFRAMEBUFFEREXTPROC) (GLuint framebuffer);
typedef void (APIENTRYP PFNGLBINDFRAMEBUFFEREXTPROC) (GLenum target, GLuint framebuffer);
typedef void (APIENTRYP PFNGLDELETEFRAMEBUFFERSEXTPROC) (GLsizei n, const GLuint *framebuffers);
typedef void (APIENTRYP PFNGLGENFRAMEBUFFERSEXTPROC) (GLsizei n, GLuint *framebuffers);
typedef void (APIENTRYP PFNGLFRAMEBUFFERTEXTURE1DEXTPROC) (GLenum target, GLenum attachment, GLenum textarget, GLuint texture, GLint level);
typedef void (APIENTRYP PFNGLFRAMEBUFFERTEXTURE2DEXTPROC) (GLenum target, GLenum attachment, GLenum textarget, GLuint texture, GLint level);
typedef void (APIENTRYP PFNGLFRAMEBUFFERTEXTURE3DEXTPROC) (GLenum target, GLenum attachment, GLenum textarget, GLuint texture, GLint level, GLint zoffset);
typedef void (APIENTRYP PFNGLFRAMEBUFFERRENDERBUFFEREXTPROC) (GLenum target, GLenum attachment, GLenum renderbuffertarget, GLuint renderbuffer);
typedef void (APIENTRYP PFNGLGETFRAMEBUFFERATTACHMENTPARAMETERIVEXTPROC) (GLenum target, GLenum attachment, GLenum pname, GLint *params);

I think that’s all I’ve done and it compiled and worked with a fresh CVS checkout.

Now I’m off to add OpenAL…


OpenAL is broken on OSX. I tried using the bundled library that comes with Leopard and freshly compiled one from the OpenAL CVS. They both output sound but playing two audio files concurrently produces a “corruption in stream queue” error eventually.

From looking at the code (openalAudioSound.cxx line 461) that prints this error, there’s a problem with OSX OpenAL’s buffer queue. The Panda OpenAL library keeps a local copy of the buffer queue and when it tries to clear the queue of used buffers the queue either returns garbage or doesn’t keep the buffers in the same order they are stored in the pandas local queue.

I then gave up trying to get OpenAL to work and moved on to FMOD and that turned out to work just fine!

  1. Download and install FMOD Ex programmers API from the FMOD homepage. I chose the development version 4.09.08.

  2. Rename the directory FMOD got installed in and remove the spaces.
    /Developer/FMOD Programmers API/
    to e.g.

  3. Add following lines to your Config.pp

#define FMODEX_IPATH /Developer/FMOD_Programmers_API/api/inc
#define FMODEX_LPATH /Developer/FMOD_Programmers_API/api/lib
  1. Compile!

  2. The libfmod_audio links to ./libfmodex.dylib in the same directory. I suppose this is a feature to make redistributing your application with FMOD easier. Therefore you have to copy the library to the panda library directory:

cp /Developer/FMOD_Programmers_API/api/lib/libfmodex.dylib /usr/local/panda/lib/

I’ve only tested the Panda Musicbox example and playing four different mp3s concurrently on both the Sfx and Music channels. Both cases worked fine and the audio glitch I had with OpenAL is gone too.


I can build with libtar if I add a typedef for ssize_t in the file dtool/src/parser-inc/stdtypedefs.h

I’m including the diff for completeness.

--- panda3d-1.5.0/dtool/src/parser-inc/stdtypedefs.h	2008-01-17 12:27:54.000000000 -0700
+++ panda3d-1.5.0-patch/dtool/src/parser-inc/stdtypedefs.h	2008-03-26 09:26:01.000000000 -0700
@@ -25,6 +25,7 @@
 #ifndef __APPLE__
 typedef unsigned int size_t;
+typedef signed int ssize_t;
 typedef int off_t;
 typedef unsigned int time_t;
 typedef int clock_t;


Although it’s only useful for compressing animation tables into Panda’s binary bam format, I had to make the following changes for FFTW support.

In my Config.pp:

#define FFTW_IPATH /opt/local/include
#define FFTW_LPATH /opt/local/lib
#define FFTW_LIBS drfftw

In panda/src/mathutil/fftCompressor.cxx I had to change the include from “rfftw.h” to “drfftw.h”.

Again, I’m including the diff for completeness.

--- panda3d-1.5.0/panda/src/mathutil/fftCompressor.cxx	2007-06-22 05:33:47.000000000 -0700
+++ panda3d-1.5.0-patch/panda/src/mathutil/fftCompressor.cxx	2008-03-28 17:58:13.000000000 -0700
@@ -34,7 +34,7 @@
 #ifdef howmany
 #undef howmany
-#include "rfftw.h"
+#include "drfftw.h"
 // These FFTW support objects can only be defined if we actually have
 // the FFTW library available.

These changes appear to be necessary because the library and include files are named differently when installed from MacPorts.


I have encountered a problem while trying to use ode (libpode).

the problem is that the module is named libpode.dylib/.so, the init function it searches at python import (genPyCode) is _initlibpode:
ImportError: Loaded module does not contain symbol _initlibpode

however it does contain a function which probably could be found using the name _initlibode. Just changing the name from libpode.dylib (and .so) to libode.dylib/.so doesnt help as it’s conflicting the the “real” libode.dylib.

Is there a way to change the panda ode library to be named pode instead of ode (internally), this should solve the problem afaik.

PS: sorry im got a cold and my mind is a bit clouded :wink: I hope you understand me never the less.

<problem solved, see next post>


I have found a way to be able to compile libpode as libode, by changing:

  • the ppremake from pode to ode
  • renaming the files pode_composite(1,2,3).cxx to ode_composite(1,2,3).cxx

however that doesnt solve the lib linking problem, as it’s also causing a “lib conflict”.

I need some way to have all ode things named pode in panda…

Well i really had a clouded mind :slight_smile:

genPyCode works without problems if i genPyCode libpandaode (not libpode)


i downloaded the panda 1.5.4 source and built, more or less according to the instructions at edalytical (thanks!), and was able to genPyCode, etc. however, when i try to import DirectStart, i get the following:

>>> import direct.directbase.DirectStart
DirectStart: Starting the game.
Warning: DirectNotify: category 'Interval' already exists
:display: loading display module: libpandagl.dylib
:display: Unable to load: dlopen(libmkl_def.dylib, 1): image not found
Known pipe types:
(all display modules loaded.)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/panda/lib/direct/directbase/", line 4, in ?
  File "/usr/local/panda/lib/direct/showbase/", line 241, in __init__
    self.openDefaultWindow(startDirect = False, props=props)
  File "/usr/local/panda/lib/direct/showbase/", line 679, in openDefaultWindow
    self.openMainWindow(*args, **kw)
  File "/usr/local/panda/lib/direct/showbase/", line 754, in openMainWindow
    self.openWindow(*args, **kw)
  File "/usr/local/panda/lib/direct/showbase/", line 521, in openWindow
  File "/usr/local/panda/lib/direct/showbase/", line 463, in makeDefaultPipe
  File "/usr/local/panda/lib/direct/directnotify/", line 130, in error
    raise exception(errorString)
StandardError: No graphics pipe is available!
Your Config.prc file must name at least one valid panda display
library via load-display or aux-display.

does anyone know what libmkl_def is or how that name might be generated? doesn’t sound like a display pipe to me.



Never heard of it. It’s certainly not part of Panda; maybe it’s part of your system or your OpenGL drivers?



no such file exists on my machine.

the error is coming from GraphicsPipeSelection::load_named_module(), but i’m not sure how the const string& name parameter is getting set to mkl_def for synthesis.

i know there is significant magic involved in the loading of prc files. as i recall, it involves looking in ./etc and then tracing the path up to the root directory, looking in etc at each step along the way. after that fails, $INSTALL_DIR/etc is checked or something like that…? what is the specific magic on OSX?

i checked the loaded config object (though i don’t know which file it was loaded from), and

>>> config.GetString('load-display')

so i’m a bit confused. i feel like i must be way off track.


The loading of prc files is not that magical. It looks in various directories, but doesn’t make up a completely new filename. The loading of the display modules is even less magic–it doesn’t even look in various directories for that one.

So, that filename isn’t being requested by any Panda code. It must be loaded indirectly by the dylibs that libpandagl pulls in, which is to say, by your OpenGL drivers. You can test this by calling dlopen(‘libpandagl.dylib’) or even dlopen(‘libGL.dylib’) (or whatever your OpenGL library is called) in a sample program.




even so, i’d like to know which prc file is being loaded. is there an introspective way to get the path? otherwise, could you confirm or deny my algorithm for finding the file, so i can inspect the prc and make sure there’s no funny business going on?

i thought it was unlikely that panda would create a string with such a bizarre name, but i thought it more unlikely that the opengl rigging distributed by apple would reference an unloadable library. other opengl stuff is currently working on my machine.


print cpMgr

will print a list of all prc files loaded and where they came from. (These are the “implicit pages”, as opposed to the “explicit pages” which are loaded by explicit calls you make at runtime.)

If you can’t get DirectStart imported enough to get the cpMgr builtin, then do:

from pandac.PandaModules import *
cpMgr = ConfigPageManager.getGlobalPtr()
print cpMgr

You can also see which file specifically defined load-display with:

print ConfigVariableString('load-display')



i’ve been working on this and am confused thusly:

in python, loading libpandagl fails, complaining about libmkl_def.dylib:

>>> selection = GraphicsPipeSelection.getGlobalPtr()
>>> selection.printPipeTypes()
:display: loading display module: libpandagl.dylib
:display: Unable to load: dlopen(libmkl_def.dylib, 1): image not found
Known pipe types:
(all display modules loaded.)

in c this code

	void * x = dlopen("/usr/local/panda/lib/libpandagl.dylib",1);


	if (x == (void *)NULL){
	else printf("pass\n");

loading fails with a different message:

% ./libtest
dlopen(/usr/local/panda/lib/libpandagl.dylib, 1): Symbol not found: _PyObject_Free
  Referenced from: /usr/local/panda/lib/libinterrogatedb.dylib
  Expected in: dynamic lookup

for completeness, opengl loads fine (no surprise, since other opengl programs have been running):

	void *  = dlopen("/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib",1);


	if (x == (void *)NULL){
	else printf("pass\n");


% ./libtest

so libpandagl fails in two different ways. the problem in the c instance seems to be some sort of library path problem, but i haven’t explored that fully.

let me also mention that i’ve successfully built and run a 1.4.x panda from CVS in the past. i can’t be certain of the exact version – it was about 15 months ago. the main differences between that (working) time and this are: building with support for opencv and nvidia cg. i also upgraded the cg framework on this machine, but since it wasn’t incorporated in the last build, i wouldn’t imagine that has much to do with it.



Hmm, wait, you mean this build–the first build that doesn’t work–is also the first build that links with Cg? That sounds highly suspicious to me. Try making a build without Cg, to see if that one works.




i rebuilt w/o cg support and ran into the problem described in this thread:

after setting up my PRC_PATH and adding the plugin-path directive to the Config.prc, everything worked fine.

so i went back and built with cg and i’m now able to open a window. ironically, i can’t really test functionality of the cg bits because i have an ati card.

incidentally, where can i find more information on this plugin-path change?



Even though Cg is an NVidia product, it does work fine on ATI cards, at least those ATI cards that support shaders at all. That’s one of the selling points of Cg: it’s platform-independent, and works on all shader-capable cards, on OpenGL and on DirectX.

What do you want to know about the plugin-path change?



By default, the plugin-path is set to /lib (or something like that) but doesn’t seem to work quite well on OSX. I thought I fixed that, but apparently I didn’t.
Normally you wouldn’t need to set it, but only on OSX, for this reason.


i’ve heard this, too. but my experience, and those of people i’ve worked with, is that ati’s cg support is fairly poor.

on the other hand, i just assumed that was the problem when the toon shader example failed. when running the (basic) demo, i get a blank screen with this error at the bottom of the window:

"Toon Shader: Video card not powerful enough to do image postprocessing"

maybe the bamboo stuff is failing in some other way, but CommonFilters.filters.setCartoonInk() returned false.

the advanced demo, on the other hand, failed in a different way:

:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (29) : fatal error C9999: *** exception during compilation ***
Segmentation fault

many other programs involving shaders fail in various ways. those that explictly load .sha shader files (as opposed to using the new-fangled auto generated ones) pause/load for a long time before posting any of the above errors, and then again before finally segfaulting. there’s no such thing as a software implementation of cg to my knowledge, so i’m not sure what the hangs could be about.

the card is plenty capable (assuming that ati is not the barrier) – its r520 architecture is on par with nvidia’s g70, supporting shader model 3.0, etc. in particular, it’s the x1800 mobile part.



this is resolved. i did have another version of the cg framework installed somewhere.

however, i still haven’t been able to get CommonFilters-related code to function as expected.


I think the problem is that ppremake doesn’t copy the .sha files on a “make install” from the direct/src/filter dir to the panda_install_dir/lib/direct/filter/ dir. You need to copy them manually.

Also, about the “not powerful enough” bug, this will be fixed in the upcoming 1.6.0 release.