Panda 1.9 runtime from source: no python?

All right, having installed various dependencies, I’ve now, I believe, successfully built the SDK, installed it, and run a test-program with it.

However, my next step is to build the runtime (…or the runtime-distributable–I’m not sure of whether the order in which they’re built is important…), and while that builds, I notice in the final output that it’s omitting Python as well–and indeed, omitting all but Zlib, OpenSSL and MFC, for that matter. The relevant libraries should be installed–as shown with the success of the SDK.

Is this to be expected, or am I doing something wrong here?

Looking at the output, I do notice a few warnings at various points, although I don’t know whether they’re relevant–the relevant sections are copied below:

WARNING: Could not locate pkg-config package gtk+-2.0, excluding from build

p3dtoolutil_composite1.cxx:(.text+0x70f8): warning: the use of `tempnam' is dangerous, better use `mkstemp'

dpkg-shlibdeps: warning: symbol XPutImage used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XClearWindow used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XCreateGC used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XCreateImage used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XMapWindow used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XCreateWindow used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XOpenDisplay used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XAllocColor used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XFlush used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XWhitePixel used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries
dpkg-shlibdeps: warning: symbol XCheckWindowEvent used by debian/panda3d-runtime/usr/lib/x86_64-linux-gnu/nppanda3d.so found in none of the libraries

The runtime does not use Python, so it is automatically omitted. You need only worry about libraries it actually warns you about at the beginning of the process. You might want to install libgtk2.0-dev, though.

The SDK, runtime and runtime distribution are built independently. Assuming no cross-contamination due to misconfigured library paths, there is no consequence to building them in a different order. Of course, you might want to use the same --host and --distributor for both the runtime and the runtime distribution - the --host can be a local file:/// URL, eg. “file:///home/rdb/panda3d/built_rdb/stage/”.

The Xlib warnings can safely be ignored since those symbols are provided by the browser.

Ah, wonderful, thank you.

I’ve noted libgtk2.0-dev as something to install before next rebuilding–thank you for that, too.

Ooh, that’s useful to know!

I already have a host parameter defined, but, being unsure of the requirements, I left it at the value used in the forum-post in which I spotted it (with the intention of solving that problem at a later point), which I believe intended to host the distributable on a local server. Being able to simply identify its location as a directory should be very handy!

As to having those two parameters in both runtime and distributable, I currently do, but only really because I wasn’t sure of whether to include them in both and so simply did on the principle that it was likely the safest course of action, I believe. ^^;

[edit]
If I may, I have another question: is it safe to omit “numpy”? My distributable build is currently tripping over its lack, and I’ve seen a few posts that indicate that it’s used for optional packages, but I’m not entirely confident of my research there–perhaps most of all, whether “pyopengl”, which I gather depends on “numpy”, is important to using OpenGL in general or is safe to leave out.

It’s just part of a series of packages we build for user’s convenience. You can just omit it. I commented out numpy and its dependencies in thirdparty.pdef.

Excellent, thank you.