Passing -soname to linker causes Linux build to fail

Compiling or Editing the Panda Source
1

I’m compiling the CVS version of Panda3d under Fedora 12, and noticed that a change last week caused panda3d to fail to startup. The build was successful, but running the tutorial programs always resulted in an error message:

DirectStart: Starting the game.
:display(warning): Unable to load: No error.
Known pipe types:
(all display modules loaded.)
Traceback (most recent call last):
File “Tut-Ball-in-Maze.py”, line 10, in
import direct.directbase.DirectStart
File “/usr/share/panda3d/direct/directbase/DirectStart.py”, line 4, in
ShowBase.ShowBase()
File “/usr/share/panda3d/direct/showbase/ShowBase.py”, line 242, in init
self.openDefaultWindow(startDirect = False, props=props)
File “/usr/share/panda3d/direct/showbase/ShowBase.py”, line 726, in openDefaultWindow
self.openMainWindow(*args, **kw)
File “/usr/share/panda3d/direct/showbase/ShowBase.py”, line 811, in openMainWindow
self.openWindow(*args, **kw)
File “/usr/share/panda3d/direct/showbase/ShowBase.py”, line 556, in openWindow
self.makeDefaultPipe()
File “/usr/share/panda3d/direct/showbase/ShowBase.py”, line 489, in makeDefaultPipe
“No graphics pipe is available!\n”
File “/usr/share/panda3d/direct/directnotify/Notifier.py”, line 131, in error
raise exception(errorString)
StandardError: No graphics pipe is available!
Your Config.prc file must name at least one valid panda display
library via load-display or aux-display.

I’ve tracked the issue down to makepanda.py r1.225 “Pass -soname to the GNU linker” Removing the ‘-Wl,soname=’ causes CVS HEAD to work again.

Absolutely loving panda3d! It’s by far the easiest 3d framework I’ve ever dealt with, and it lets me create fully functional games in my favourite language, python!

Keep up the good work

–

james

2

Hi, and welcome to the Panda3D forums!

I think I get what’s going wrong here. Makepanda is incorrectly compiling libpandagl.so as dynamic library, rather than a module.
I’ll check in a fix soon - thanks for reporting the problem!

3

And I’ve just checked in a fix. I’m still passing -soname to the linker, but am not doing it with the version suffix anymore for libpandagl.

4

Just built a new CVS checkout and I have the same problem. I’ll try to look into it later.

Also, I’ve got some patches to make panda3d compile against openssl-1.0 beta (used in Fedora 12), how do you prefer submission of them?

5

Either via my e-mail address or via the bugtracker. E-Mail is probably easier though.

6

I’ve just checked in a fix that omits the “-soname” option for libpandagl, etc.

7

That works! Thanks ever so much.

I’ll clean up the openssl stuff and send it on.

8

With a CVS update to Nov 28, I’m having the same problem again. I’ve looked at makepanda.py and figured out that it’s not the soname causing the issue any more, as the code for that is wrong, but I get the same issue weither the soname line works or not.

My C++ skills are many years out of use, but I’ve followed it as far as abspath.is_regular_file returning 0 in load_dso when trying to load libpandagl.so. The search path is “” but I lost it trying to figure out if that is handled correctly.

9

You can add a definition in your Config.prc to indicate the specific path it should search for your .so files:

plugin-path /my/panda/lib/dir

David

10

That causes it to find the pandagl.so, but now it can’t find the model files for the project. I’m just running the Ball-in-Maze sample. What changed that would case it to no longer be able to find paths to anything? This worked fine just a few days ago.

I’ll try to dig through the commit logs to see if I can find it.

11

Does putting this in Config.prc solve the problem?

model-path .
12

Whoops, the model issue was a false alarm. I had done a build makepanda.py --nothing --use_python to try to save compile time, which meant there was no zip support compiled in. Once I re-compile with --everthing (which is about 10 minutes faster than --nothing?!?) I get the same problem with the plugin loader path but the models are loadable.

I’m using the --installer option to makepython.py to create an RPM file on my Fedora 12 machine, with some patches to make the rpmbuild actually work, so the module path is /usr/lib64/panda3d. Since this is the install location, shouldn’t Config.prc already know about that?

13

It should. I’ll take a look at what’s wrong.

If you need patches to make the rpmbuild work, feel free to send them to me via my e-mail address.

14

Okay, I’ve just checked in a fix for the problem to CVS. Thanks for reporting!
(The plugin-path change should no longer be necessary.)