[Linux] Unable to load libpandagl.so


I’m using the PP system on ubuntu 8.04. The build was mostly very smooth, and I’m on the step of trying out pview but I get this error:

:display: loading display module: libpandagl.so
:display: Unable to load: No error.

I did set up the Config.prc file as well, but no change. I do have this in a non-standard location: ~/panda/panda3d, rather than in /usr/local. I do have the PATH and LD_LIBRARY_PATH variables set so it should be finding the libs. libpandagl.so did get built and is in the right place. I didn’t see any errors during compiling. I’m sure it’s something simple.

pview doesn’t rely on python, does it?



ps sorry, I meant to post this as a reply to another thread about exactly the same issue, but clicking “reply” keeps throwing me back to the board index.

This means either it didn’t load your Config.prc file, or if it did load it, your Config.prc file doesn’t include the line “plugin-path /blah/blah/blah”, naming the directory it should search for libpandagl.so.


Oh, of course! That makes sense. I thought it just need LD_LIBRARY_PATH. thanks!

I ran into this problem myself after a recent compile on Windows.

Am I to understand that Panda will now only dynamically load shared libraries that appear in directories specified in “plugin-path”?

That’s seems fine, but perhaps the default behavior should be a little nicer? Right now, when plugin-path is set to “”, it resolves to “.”, which is seldom where you want Panda to look for shared libraries.

If there was some way to specify the “Panda base directory”, it could default to “/lib” or something similar.

You can set it to “$PATH” to try and capture the previous behavior, but ConfigVariableSearchPath doesn’t seem to convert Windows style paths to Panda style paths.

Without altering Panda, it seems like the best solution for my purposes is to define an environment variable (like $PANDA_LIB), set plugin-path to that and have our Panda installer set the variable during installation.

Is there a better solution? What does the ETC Panda installer do, just force users to set plugin-path themselves?

“” is supposed to resolve to the same directory that contains libp3dtool.dll. I’m not sure why that’s not working for you.

FYI, ConfigVariableSearchPath does automatically convert Windows-style pathnames, but it doesn’t understand a semicolon-separated string (it wants each directory name to be given a separate entry).

I agree the default behavior of plugin-path leaves something to be desired. There should be a way to specify “search the system path”.


Another option is to use something like this:

plugin-path $THIS_PRC_DIR/../lib

The environment variable $THIS_PRC_DIR is filled at runtime with the directory name that contains the particular prc file that is currently being parsed. So if your dll is in a directory relative to that prc file, you can give a relative path to it.


Yeah, I was wondering about that. But the comment in load_dso.cxx resolve_dso says:

// This is a special case, meaning to search in the same
// directory in which libp3dtool.dll, or the exe, was started
// from.

which, given the “was started from”, can reasonably be interpreted as “the current working directory”, so I figured it was behaving as expected.

ExecutionEnvironment::get_dtool_name returns the path to the python executable for me:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pandac.PandaModules import ExecutionEnvironment
:interrogatedb(warning): Classes Http_Request and Socket_TCP share the same TypeHandle value (387); check class definitions.
>>> ExecutionEnvironment.getDtoolName()

But it looks like something is going on even earlier. If I don’t specify plugin-path in any prc, I see this:

>>> from pandac.PandaModules import ConfigVariableSearchPath
>>> ConfigVariableSearchPath( "plugin-path" )

But if I put “plugin-path ” in one of my prc files, I get this:

>>> from pandac.PandaModules import ConfigVariableSearchPath
>>> ConfigVariableSearchPath( "plugin-path" )

Unfortunately, even using “plugin-path ”, Panda still can’t load things:

:display: loading display module: libpandadx9.dll
:display: Unable to load: Path not found
:display: loading display module: libpandagl.dll
:display: Unable to load: Path not found

Yes, sorry, that’s what I meant.

“plugin-path $THIS_PRC_DIR/…/lib” works for me.

Perhaps that should make it into panda.prc.pp? Or perhaps the problem with “” should just be resolved.

Looks like there are at least two different problems.

Strange that you see the default value appears to be “.”, since I believe the default value is set to “” in code. Perhaps there actually is a definition for it in a prc file that you’re not aware of. Try:

print ConfigVariableString("plugin-path")

to display all the prc files that define plugin-path (note the use of ConfigVariableString here instead of ConfigVariableSearchPath).

Well, this explains why is not working when you explicitly set that, too, unless your libpandagl.dll etc. files are in the /Python25 directory. It sounds like it fell back to looking for the exe directory, which it should only do if it fails to find libp3dtool.dll. Hmm, the name “libp3dtool” is only generated by makepanda for the public Panda distributable. When built using ppremake, I believe it still generates the filename “libdtool.dll” instead. I suppose this logic for should be smartened up to know which dll name it ought to be looking for.


I thought it was strange myself. I did a full directory search on “plugin-path” to see if it was being set anywhere else, but all I came up with was the default instantiation in config_util.cxx:

ConfigVariableSearchPath plugin_path
("plugin-path", "<auto>",
 PRC_DESC("The directories to search for plugin shared libraries."));

I get this:

>>> print ConfigVariableString("plugin-path")
ConfigVariable plugin-path:
  plugin-path   (default value)

The directories to search for plugin shared libraries.

>>> print ConfigVariableSearchPath("plugin-path")

That makes sense.

Ah, I know what this is about. Use:

print getPluginPath()

instead. ConfigVariableSearchPath objects are unfortunately a little different from most other config variable types, in that their default value is not stored globally, but only on the local instance. This means that if you want to see the default value properly, you need to print the particular instance that Panda uses, which is returned by the global getPluginPath() function.


OMG its JasonPratt, user #2

When i generate my exe (for windows) game distribution i stick all the panda3d dills into the ./panda3d/ folder. How does this impact the Plugin Path?

If you have a makepanda-built version of Panda, with libp3dtool.dll, it should just work as long as all of your dll’s are in the same directory with libp3dtool.dll.

If you have any other configuration, you will need to define plugin-path in your Config.prc correctly to give the path to your loadable dll’s like libpandagl.dll.


>>> print getPluginPath()

Okay, so is, in fact, being used, and it looks like the problem is just from the libdtool naming issue.