This means that in order to develop C++ libraries for python, you need some C++ header files that come with python. These header files are called the “python SDK”.
Linux distributions often include two packages like:
The second package, the ‘dev’ package, is the one that contains the SDK (the header files). Now, I don’t know what mandrake calls this package. But you need to find it.
More difficult is the fact that mandrake doesn’t include several of the tools you need to build panda. For example, mandrake doesn’t include ‘bison’ and ‘flex’, tools which are normally standard under linux but for some reason are missing from mandrake.
On redhat, building an rpm is trivial. All you have to do is type
rpm -tb panda3d-1.0.4.tar.gz
That’s all. It does the rest. The RPM ends up in /usr/src/redhat/RPMS
I tried the same thing on mandrake, and it gave some error message that made it clear that the rpm-build tools are not installed. I spent a few hours trying to figure out how to get the rpm-build tools, but I failed.
So really, it’s a question of knowing where to get the right software.
Update: when you figure it out, tell me. I’d love to distribute a mandrake RPM.
Now, after you install that, it will probably fail again at a different place, saying something like “zlib.h not found” or maybe “png.h not found” or some other missing header files. Look for the relevant “-devel-” packages. That’s what’s missing.
OK, got past that one, on to the next one…is there an emoticon for “sigh”?
I did a google of libpystub.so and came up dry after I perused all the RPMs installed and not installed and didn’t find libpystub.so in any of them with “python” in the RPM name. Then I had the bright idea of searching my own system and, as I’m sure you know, found it in panda3d-1.0.4/built/lib/libpystub.so
In the built/lib directory, libpystub.so and libdtoolconfig.so have ownerships of root/root while the rest of the files are owned by my user-id. Could this have come from compiling initially under my user-id and then compiling a second time under root?
I tried compiling under both root and my user-id. No joy.
Here’s the deal: makepanda builds the library ‘libpystub.so’, then makepanda builds the executable ‘interrogate’ which uses ‘libpystub.so’, then makepanda tries to run interrogate. In order for it to be able to run ‘interrogate’, the directory containing ‘libpystub.so’ needs to be in your shared-library path. Now, supposedly, makepanda contains the necessary code to put the built/lib directory into your LD_LIBRARY_PATH. But apparently, that code isn’t working. Somebody reported this problem before, but then the problem spontaneously went away, so we couldn’t diagnose it. Could you analyze?
Makepanda doesn’t set LD_LIBRARY_PATH permanently. It only sets it for its child processes. Either it’s not really setting it, or it’s setting it and it’s having no effect.
I suppose I’d delete ‘interrogate’ and replace it with a script that prints out LD_LIBRARY_PATH. That will tell you whether or not makepanda is really setting LD_LIBRARY_PATH. The script would look like this:
Exactly right. You can always get the real ‘interrogate’ back by deleting it and letting ‘makepanda’ rebuild it. This is just a test to see what’s going on.
Sorry it’s taking me so long to respond. I’m visiting relatives. Starting tomorrow, I’m not going to be available hardly at all, so you may need to seek help from other people on this forum. There are some smart ones here.
to the "env | grep LD_LIBRARY_PATH " I got nothing.
I did an “env” just to make sure I hadn’t mispelled the search string and nothing even close.
to the “cat /etc/ld.so.conf”
I start makepanda with "makepanda/makepand.py --everything
I’ve got a “built” directory so it seems to me that the compile worked at least once but i couldn’t get panda to start in the manner that the docs suggested it should so I figured something was less then right.
did a “makepanda/makepanda.py --everything” as user and got the following:
Starting compile in "panda/src/chan" (15 min 15 sec):
g++ -ftemplate-depth-30 -c -o built/tmp/chan_composite1.o -I"/usr/include/python2.3" -Ithirdparty/linux-libs-a/nspr/include -Ibuilt/tmp -Ipanda/src/chan -Ibuilt/include -O2 -DBUILDING_PANDA panda/src/chan/chan_composite1.cxx
built/include/pandaNode.h: In member function `virtual TypeHandle PandaNode::force_init_type()':
built/include/pandaNode.h:413: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:https://qa.mandrakesoft.com/> for instructions.
The above seems like the relevent stuff. If more is needed, let me know and I’ll run the compile again and post more.
Funny thing is, after my very first compile I was getting what seemed to be some Panda-related activity. The mouse pointer would turn into a cross-hair pointer while within the console window. If I clicked within the window, while the mouse pointer was a crosshair, that would terminate whatever it was that was running.