Mac OSX port?

I was wondering how hard it would to compile for mac OSX (10.3.8),
has anyone already done this? If so could you please pass it on?

when will there be an official release of osx?

I would really like to share this with a new media class ASAP.

  • Jarrad Hope
  • brainmeat (a,t) mypetcaretaker (d,o.t) com

I believe there was an earlier post about the same thing.

Are you referring to
because that does not answer any of my questions :confused:

OK, just wasn’t sure if you had seen it or not.

so the answer to my question is not available to public? :confused:
I eally like the idea of panda3d

The answer is - right now, there’s nobody at ETC working on an OSX port. We just don’t have the manpower right now. Besides, we don’t have any macs. I also believe there’s nobody at Disney working on an OSX port.

I don’t know whether or not this would be a very hard thing to do. Who knows… it already runs under Linux, SGI, and Windows, so it must already contain most of the code you need.

Looking forward to an OSX port… even if its just an X11 port for now. What happened? Earlier, there was talk of an OS X port. Did it all kinda fizzle? Did the guy doing it graduate? :slight_smile:

Good work in trying to bring together lots of VR tools. Hope it helps unify the field.


At Disney, we do still have plans to finish the OSX port eventually, but the effort has been temporarily postponed while our engineers work on more immediate issues.

Since OSX is derived from BSD, which is very similar to Linux, one would think that an OSX port would be pretty simple. In practice, it appears that many fundamental things have been changed in the OSX implementation, such as the mechanism by which third-party libraries are linked in, the way static initialization is performed, and other silly fiddly little things that make the port a bit harder than you’d expect.

A couple of people, outside of CMU or Disney, have offered to contribute from time to time, and seemed to make some progress, but then they went away without contributing anything, so we don’t really know what happened.

Would you like to take another stab at it?


Thanks for the replies!

I wouldnt know how to port the code, although im sure it snot difficult from the linux source…:blush:

Thanks again, good luck!

I spent a bit of time on this this evening. Due to the custom build system, the port is likely to be somewhat painful. I haven’t even got around to figuring out how Panda3D opens a window yet, which is likely to be the other tricky bit…

In thirdparty/linux-libs-a, there are these files that are required:

I know what fmod, Cg and CgGL are, and obtaining them for the Mac is not a problem. For the rest, I have no idea. Can anyone help me out?

fftw - “fastest fourier transform in the west.” I believe this is required if you want to be able to compress and decompress animations.

nspr - “netscape portable runtime” Mainly a wrapper around TCP/IP, to make it more portable from OS to OS.

plc, plds - part of NSPR.

vrpn - “virtual reality peripheral network” is an interface we use to hook up weird gizmos like head-mount displays and motion trackers to panda3d.

quat - part of vrpn.

Also, don’t forget there are two custom build systems. See which one ports more easily.

Furthermore, please realize that Panda can be built without any of the thirdparty libraries. They all just provide support for optional features, such as compressed animation files. (Some of these features some might not consider “optional”, such as Python scripting, or even OpenGL rendering, but the fact is that Panda can compile without them and can still do useful work.)

In any porting effort, it would make sense to get core Panda working first, without any of this add-on stuff.


using --nothing I’ve got a bit further.

Now it says

Cannot find source file fdisplay_composite1.cxx

Sure enough, that file doesn’t exist. Should it? Its name seems to be hardcoded into, and it’s only mentioned in one place in that file, suggesting it’s not supposed to be a product of another build step.

Doesnt appear at all in the version of in the CVS. Maybe update all your directories from CVS and try again?


This really doesn’t seem worth the effort. Panda3d really is the biggest bloated mess of dubious C++ code, and my computer is barely usable as it chugs away at the compilation :confused:

Anyway, in case someone else can benefit from what I’ve done, I’ve put a patch for the 1.0.3 tarball here:
which gets you as far as reported in my last message.

Good luck to anyone in their future efforts to port this…

We do appreciate your contribution; I’m sorry for your negative feelings.

It appears that your patch includes the following change (excerpted):

@@ -4564,7 +4655,7 @@
 if (sys.platform != "win32"):
     IPATH=['panda/src/glxdisplay', 'panda/src/gobj']
-    CompileC(ipath=IPATH, opts=OPTS, src='glxdisplay_composite1.cxx',     obj='glxdisplay_composite1.obj')
+    CompileC(ipath=IPATH, opts=OPTS, src='fdisplay_composite1.cxx',     obj='glxdisplay_composite1.obj')
     Interrogate(ipath=IPATH, opts=OPTS, outd='', outc='libglxdisplay_igate.cxx',
                 src='panda/src/glxdisplay',  module='pandagl', library='libglxdisplay', files=['glxGraphicsPipe.h'])
     CompileC(ipath=IPATH, opts=OPTS, src='libglxdisplay_igate.cxx',      obj='libglxdisplay_igate.obj')

Where you have replaced the occurrence of “glxdisplay_composite1.cxx” with “fdisplay_composite1.cxx”. Perhaps this is an unintentional typo? It probably explains your error above.


Compilation time has nothing to do with the quality of the code. I think that was a little unfair. Maybe you need to upgrade.

heh, that certainly would explain that failure :slight_smile:

The compilation time is just absurd and annoying. C++ files shouldn’t need 600+ MB of RAM to compile. The quality of code is as judged by the number of warnings spewed out during the build.

I’ve put the fixed patch up at the same URL. It doesn’t get much further – barfs trying to parse glext.h. I’ve tried defining various things for interrogate, but nothing seems to help, and the error message is totally uninformative.

Do you mean, interrogate fails trying to parse glext.h, or do you mean the compiler fails? If it is interrogate, that’s strange, since interrogate isn’t supposed to run on any of the OpenGL code (and you probably should start out with interrogate disabled anyway, and even OpenGL for that matter, until you’ve got the core code ported). If it is the compiler, that’s a different problem, and glext.h isn’t even part of our code anyway–it was downloaded from

I agree that it would be nice if compilers didn’t consume many megabytes of ram and vast numbers of CPU cycles. And it would certainly be nice if they gave useful and informative error messages. But C++ is a big, complicated language, and Panda3D contains a lot of code.

I don’t know what you’re talking about when you complain about warnings. Every different version of a compiler has its own set of pet peeves it issues warnings about; we make an effort to keep compiler warnings to a minimum (zero) on the compilers we use every day. Nothing I can do about warnings on a compiler I’ve never used before.


Interrogate fails.

The compiler is g+±3.3, presumably the same one as you’re using on Linux.

How do I disable interrogate and OpenGL? --nothing doesn’t do it, and doesn’t have an obvious option to do it either.