Error in panda3d.py (C to Python imports) panda.egg

Scripting Issues
1

I’ve been trying to to use the exposed C functions in Python (namely egg and core) to do some tests on getting a Python based egg editor. When using the new import system from a few months ago I get an error that libpandaexpress_d doesn’t exist. This is a debug library right? and after digging through panda3d.py I saw this line

if cls.sys.platform == "win32":
      filename += "_d"

got rid of it and no more errors. Although I’m not so sure these functions are working as exepected due to the C to Python exposure. Granted I can see the need to use the debug extension but shouldn’t it only check to see if your interpreter is a debug one?

Hope this may help someone down the line.

2

Hm… we use the fact that it’s a debug interpreter to determine if we’re also using a debug version of Panda3D. If you make a debug build of Panda3D, the dlls will have the _d suffix.

3

But does it always have to be a debug interpreter? shouldn’t it be able to use the standard SDK libs instead of the _d ones? I have a debug build of both the panda source and python, but I was just trying to use the standard interpreter in Pype to run this. Should I be using my debug build of Panda at all times to access these funcs?

4

I’m not sure what you’re asking. Evidently, you don’t have a debug build of Panda, or you would have libraries named libpandaexpress_d.dll, instead of libpandaexpress.dll.

In Windows, it is important that you not mix-and-match debug and release builds in the same executable. This is particularly important for C++ code, but it is also true to a lesser extent for plain C code, for instance the Python interpreter. The reason for this has to do with the way Microsoft changes the fundamental behavior of malloc/free in a debug build; blocks allocated via a debug malloc cannot be freed by a release free, and vice-versa.

So, if you a running a python.exe that is compiled as a debug build (it is usually named pythond.exe or python_d.exe), then our scripts will automatically look for libpandaexpress_d.dll, which is also compiled as a debug build. If you load libpandaexpress.dll instead, you risk mysterious crashes resulting from improper mixing-and-matching.

David

5

That’s the weird thing. I didn’t even have a debug build of python on the system i was using (it was the plain old python.exe that came with 2.6.4). And yet still the panda import system went looking for libpandaexpress_d. I guess I wasn’t clear on that point, sorry for the confusion. That’s why I edited that line in panda3d.py. It seemed that even though I didn’t have a debug interpreter (ie. python.exe not pythond), it was still looking for a debug pandaexpress.

EDIT: it was also a standard fresh install of Panda 1.7.0 from here. not a CVS build

6

There are two possible reasons.
First of all, this happens if the Python interpreter name ends with _d.exe:

            if sys.executable.endswith('_d.exe'):
                dll_suffix = '_d'

Secondly, it could happen if someone sets sys.dll_suffix to ‘_d’.

Can either of this be the case?

7

Yeah I saw that line when I first got the error, I guess i could do a simple print and check to see if that’s where it’s happening. I’m not sure how to exactly check that the sys.dll_suffix is being set or not otherwise though.
I’m 90 percent positive there was no python_d.exe anywhere on the system I was trying this on though. I tried to search for it and run it from the command line, but I didn’t see it. I’ll check around again and get back later today. I’ll let you know what happens. As always thanks for the time and help.

~Andrew

8

I checked around. There was definitely NO python_d.exe on the system, and no panda debug build. And unless Pype and/or Eclipse will automatically change things somehow, then I don’t think there’s a real reason that libpandaexpress should get the _d suffix in this case. Should there be some modification to panda3d.py to prevent this? As I said earlier I got around it by changing the suffix to ‘’ instead of ‘_d’ when the platform is win32. Thanks again

~Andrew

9

Could you add some print statements there to see what’s happening? In particular, print out sys.executable and getattr(sys, “dll_suffix”, None).

10

Here’s the output:
from
print “getattr”
print getattr(sys, “dll_suffix”, None)
print “executable”
print sys.executable

getattr
None
executable
C:\Panda3D-1.7.0\python\python.exe

[/code]

11

Oh and by the way here’s the actual error from my program including the offending line:

Traceback (most recent call last):
  File "test.py", line 195, in OnOpen
    test = p3dE.EggData()
  File "C:\Panda3D-1.7.0\panda3d.py", line 145, in __getattr__
    mod = self.__manager__.libimport(self.__library__)
  File "C:\Panda3D-1.7.0\panda3d.py", line 101, in libimport
    if not cls.prepared: cls.__prepare()
  File "C:\Panda3D-1.7.0\panda3d.py", line 67, in __prepare
    raise ImportError, "Cannot find %s" % (filename)
ImportError: Cannot find libpandaexpress_d
12

OK, I’m stumped. That looks good. How could it get the dll_suffix otherwise? :confused:

13

Hmm, the line in question in panda3d.py:

        filename = "libpandaexpress" + cls.dll_suffix
        if cls.sys.platform == "win32":
            filename += "_d"

Should that be:

            filename += dll_suffix

?

Edit: actually, no, dllsuffix is already in the lines above. These extra lines don’t seem to belong here at all. Maybe a bad merge put them there by mistake?

David

14

That was my thought, but I wanted to see if I was doing something wrong with the newer import system

15

Whoops! That’s a silly mistake indeed, and I wonder why it worked for me when I tested it on Windows, and why it worked for others.

Just checked in a fix. Those two lines should not be there.