Cannot find the python SDK


#18

Ah ha! I think I have it.

Try running, as root, the command “ldconfig”. Then try to run makepanda again as a normal user.

David


#19

results of running ldconfig as root:

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.

Allen


#20

Hmm, a compiler core dump, not such a good thing. What a bucket of worms this is! What version of the compiler are you running?


gcc --version

Did you try making clean by blowing away the built directory first?

The crosshairs thing certainly isn’t Panda behavior. I’ve never heard of that before. Does it happen when you compile other programs?

David


#21

I did’nt blow away the “built” directory. Should I have?

re: the crosshairs thing…

Nope. Never saw it before. I just assumed it was Panda-related. Not, hey?


#22

Yes, please do try starting from a clean build.

Nope, never heard of that crosshairs thing. Could it be a Python thing under Mandrake for some reason?

David


#23

Never saw the crosshair mouse pointer before and don’t have a clue why it might show up.

Scrubbed “built” and fired off another build. It pooped out on what looked like the absence of the TIFF libraries. I installed everything that looke vaguely TIFF-related, scrubbed “built” again and have another build going.

I’d cross my fingers but I can’t type that way.


#24

OK, need some help here.

I know Panda’s looking for a library but using the search string “gl” pulls up too big a list to install it all. There’s a heap of stuff with “glibs” in the name but it’s too big a list to install all of unless I have too.


#25

It’s looking for a file named libGL.so or libGL.a. On RedHat those files are in /usr/lib; they may be elsewhere (or not installed by default) on Mandrake.

David


#26

In Mandrake libGL.so is in /usr/X11R6/lib

I can’t find libGL.a on the system.


#27

libGL.so is sufficient. You only need one or the other.

Probably makepanda needs to be modified to put /usr/X11R6/lib on the -L path when you are compiling on Mandrake. In the meantime, you can cheese this out by linking the critical files into /usr/lib. Do the following command as root:


ln -s /usr/X11R6/lib/libGL*.so /usr/lib

David


#28

could I stick that in /etc/ld.so.conf?


#29

You could try that–were you the one who added the panda build directory in there? Remember always to re-run ldconfig after you modify ld.so.conf.

But I’m not sure if that would help; you need to tell the compiler where to find the library, not the loader. I’m not sure if gcc looks up in ld.so.conf for its libraries. It might.

David


#30

Yeah, I added build/lib to the ld.so.conf. I didn’t add /usr/X11R6/lib to the ld.so.conf since the consensus seemed to be that it wouldn’t do any good.

I did the “ln -s /usr/X11R6/lib/libGL*.so /usr/lib”, zapped the build directory and did a makepanda/makepanda.py --everything. Pooped out in three minutes with:


../../../built/bin/interrogate: error while loading shared libraries: libpystub.so: cannot open shared object file: No such file or directory

So I ran a locate on libystub.so and it’s in panda3d-1.0.4/built/lib/libpystub.so

The compile ran lot’s farther before I did the “ln -s /usr/X11R6/lib/libGL*.so /usr/lib”

Are the two related? Should I rm the symlinks?

Allen


#31

No, don’t remove the symlinks; they’re still needed to link with the libGL libraries.

You should consider removing the “built” directory from your ld.so.conf file. That’s what actually confused makepanda into not adding the library name to LD_LIBRARY_PATH–and since you hadn’t run ldconfig recently, the system wasn’t searching the path by default. I think that may be related to the problem you’re having with interrogate now.

Try removing this line now, and then re-running ldconfig.

David


#32

I think I’m moving forwarder but I’m not sure.

Here’s the tail end of the compile:

I tried starting Panda and got this:

Allen


#33

Hmm, we appear to have come full circle. So now it appears that, after the build, genpycode is in fact being run–although it’s strange that I don’t see any meaningful output from it. Maybe it’s still erroring out?

What happens if you run genpycode on the command line by itself? Maybe after you run:


export LD_LIBRARY_PATH=/my/path/to/built/lib

David


#34

Since this last compile ran longer then any of the others I was hoping I was getting closer to having Panda work. Oh well.


export LD_LIBRARY_PATH=/home/allen/Downloads/Panda/panda3d-1.0.4/built/lib
[built]# bin/genpycode
enumerate is already present in __builtin__
Segmentation fault

#35

The segmentation fault at startup is as if there were a mismatch in the library versions somehow, or some other problem that happens at static init time. This will be difficult to debug, but I think we can get there, if you have patience.

(Side comment–you certainly seem to be especially unlucky! It seems that there are many different things about your particular system that are just designed to cause us trouble. I do appreciate your patience with this process so far; hopefully, all of this work we are doing now will be of value not only to you, but also to other people who have a similar system to yours.)

Let’s see if we can even load your .so’s at all without crashing. Try something like this:


test_interrogate libpandaexpress.so

It should say something like:

Loading libpandaexpress.so
:interrogatedb(error): Unable to find libdownloader.in on .
:interrogatedb(error): Unable to find libexpress.in on .

0 manifests:

0 globals:

0 global types:

0 global functions:

Then try:


test_interrogate -p /my/path/to/built/etc libpandaexpress.so

(Where /my/path/to/built/etc is the directory that contains all of your generated *.in files.) It should spam a whole bunch of output about function names and parameters and such.

Also try this experiment:

ppython
>>> import libdtoolconfig
>>> dir(libdtoolconfig)

It should list a bunch of interface names like ‘interrogate_wrapper_unique_name’ and ‘interrogate_add_search_directory’.

If any of these steps crashes, it will help us to know where to narrow the search.

David


#36

in response to “built/bin/text_interrogate libpandaexpress.so”


bin/test_interrogate: error while loading shared libraries: libpystub.so: cannot open shared object file: No such file or directory

in response to “bin/test_interrogate -p /home/allen/Downloads/Panda/panda3d-1.0.4/built/etc libpandaexpress.so”


bin/test_interrogate: error while loading shared libraries: libpystub.so: cannot open shared object file: No such file or directory

in response to:


ppython
>>> import libdtoolconfig
>>> dir(libdtoolconfig)

I got


>>> import libtoolconfig
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named libtoolconfig
>>> dir(libtoolconfig)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'libtoolconfig' is not defined
>>>

Also, the Panda/panda3d-1.0.4/built/etc directory has only two files in it: Confauto.prc and Config.prc.

(Return side comment - believe me, this isn’t my idea of fun. I’d really rather Panda just work so I can get on with my project but as long as I can get help, I’ll keep plugging along.)

Allen
[/code]


#37

Hmm, try running:


export LD_LIBRARY_PATH=/my/path/to/built/lib

and then try the test_interrogate commands again.

It looks like there was a minor typo in your import statement above; you imported “libtoolconfig” instead of “libdtoolconfig”.

It also just occurred to me to ask: can you run pview on the command line by itself? Especially after the above LD_LIBRARY_PATH command.

David