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?
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
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.
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.
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
In Mandrake libGL.so is in /usr/X11R6/lib
I can’t find libGL.a on the system.
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/libDavid
could I stick that in /etc/ld.so.conf?
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
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 directorySo 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
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
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
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/libDavid
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 faultThe 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.soIt 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
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 directoryin 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 directoryin 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]
Hmm, try running:
export LD_LIBRARY_PATH=/my/path/to/built/liband 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
export LD_LIBRARY_PATH=/home/allen/Downloads/Panda/panda3d-1.0.4/built
bin/test_interrogate libpandaexpress.so
Loading libpandaexpress.so
:interrogatedb(error): Unable to find libexpress.in on .
:interrogatedb(error): Unable to find libdownloader.in on .
0 manifests:
0 globals:
0 global types:
0 global functions:
bin/test_interrogate -p /home/allen/Downloads/Panda/panda3d-1.0.4/built libpandaexpress.so
Loading libpandaexpress.so
:interrogatedb(error): Unable to find libexpress.in on /home/allen/Downloads/Panda/panda3d-1.0.4/built
:interrogatedb(error): Unable to find libdownloader.in on /home/allen/Downloads/Panda/panda3d-1.0.4/built
0 manifests:
0 globals:
0 global types:
0 global functions:
bin/ppython
Python 2.3.3 (#2, Feb 17 2004, 11:45:40)
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libdtoolconfig
Segmentation fault
bin/pview
Known pipe types:
glxGraphicsPipe
(all display modules loaded.)
:display:glxdisplay(error): OpenGL GLX extension not supported on display ":0.0".
:framework(fatal): open_window: failed to create gsg object!
:framework(error): Unable to create window.Ok, I observe:
(1) libdtoolconfig.so can be loaded by a pure C++ program without crashing. Therefore, it is not crashing in static init.
(2) libdtoolconfig.so crashes immediately when loaded in a Python program. It follows that it is crashing in initlibdtoolconfig(), which only makes a single call to a simple Python interface function.
Are you absolutely sure that the Python SDK you have installed and are using to build Panda exactly matches the version of Python that you are running with? It sure does seem like you have some kind of Python version mismatch here–the crash occurs the very first time a Python function is called from Panda code.
Also, the fact that pview fails with that particular error message indicates another problem you will have eventually, completely aside from the Python issue: your OpenGL is not fully configured. In particular, you need to enable the glx extension in your X server. This is not related to Panda; this is part of the operating system installation. Fixing this may be as simple as adding a LoadModule “glx” line to your XF86Config, but there’s probably more to it; you’ll need to consult with your graphics card manufacturer’s advice and/or Mandrake’s advice.
David
From the Mandrake Control Center:
Name: libpython2.3-devel
Version: 2.3.3-2mdk
Size: 14718 KB
Name: python
Version: 2.3.3-2mdk
Size: 15116 KB
Name: python-base
Version: 2.3.3-2mdk
Size: 893 KB
Name: python-numeric
Version: 23.1-2mdk
Size: 1462 KB
That’s everything that has “python” in it’s RPM name that’s installed.
There’s a bunch of RPMs with “python” in the name that aren’t installed. It’s a fairly long list. Should I post that? It’ll take a while to compile the list.