won't compile (Debian amd64)

Compiling or Editing the Panda Source
21

Hmm. Try add -ldtoolutil to the link line for apply_patch. libdtoolutil.so is the library that actually defines this symbol.

David

22

I executed it manually:

> g++ -o built/bin/apply_patch -Lbuilt/lib -L/usr/X11R6/lib built/tmp/apply_patch_apply_patch.o -lpandaexpress -lpanda -lp3dtoolconfig -lp3dtool -lp3pystub -lz -lssl -lpthread -ldtoolutil
/usr/bin/ld: cannot find -ldtoolutil
collect2: ld returned 1 exit status

So no good. And I wouldn’t know where to add it in makepanda.py, in case that should make a difference.

23

Makepanda appends “p3” to all the library names — there’s another linux package out there that contains a library called “dtool.so” or something like that, so I added the “p3” to avoid name conflicts. So it would be -lp3dtoolutil

24

Hm, running it manually, seems to make no difference:

> g++ -o built/bin/check_adler -Lbuilt/lib -L/usr/X11R6/lib built/tmp/check_adler_check_adler.o -lpandaexpress -lpanda -lp3dtoolconfig -lp3dtool -lp3pystub -lz -lssl -lpthread -lp3dtoolutil
/usr/bin/ld: cannot find -lp3dtoolutil
collect2: ld returned 1 exit status

How would I added this into the makepand.py? I assume it simply has to build this p3dtoolutil lib first…

25

Wait. I just realized — there is no dtoolutil.so! The two build systems, ppremake and makepanda, are different in a number of ways. Makepanda builds a few big DLLs, and ppremake builds a lot of small DLL’s. David has more experience with ppremake, which creates a DLL called dtoolutil. But makepanda doesn’t do that.

I don’t know why it’s not defining panda_version_1_4_1, but it’s not because you left a library off on the command line.

26

Hm, dtool/src/dtoolutil/checkPandaVersion.cxx line 25 had this:

EXPCL_DTOOL int panda_version_1_4_1c = 0;

Removing the c seems to make it compile on a bit, and after fixing another 64-bit pointer conversion, it ends up here:

Copying "models/zup-axis.egg" --> "built/models/zup-axis.egg"
built/bin/pzip built/models/zup-axis.egg
built/models/zup-axis.egg.pz
built/bin/genpycode
Importing code library: libpandaexpress
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/home/elias/dl/panda3d-1.4.1/built/direct/../../direct/src/ffi/jGenPyCode.py", line 94, in ?
    DoGenPyCode.run()
  File "/home/elias/dl/panda3d-1.4.1/built/direct/../../direct/src/ffi/DoGenPyCode.py", line 291, in run
    generateNativeWrappers()
  File "/home/elias/dl/panda3d-1.4.1/built/direct/../../direct/src/ffi/DoGenPyCode.py", line 253, in generateNativeWrappers
    exec('import %s as module' % moduleName)
  File "<string>", line 1, in ?
ImportError: /home/elias/dl/panda3d-1.4.1/built/lib/libp3dtoolconfig.so: undefined symbol: Py_InitModule4_64
27

I’d like to mention: you are at 99.9% complete. Genpycode is the very last step in the build process. So don’t get frustrated.

The only problem left seems to be that it is having trouble recognizing the “.so” files as being python-loadable. I unfortunately don’t know much about that process — David will help, if he is around.

Weird about “1.4.1c”. I wonder where that came from.

28

The “c” is appended by ppremake for any user-built version, e.g. a version checked out directly from cvs and built according to the ppremake instructions, as opposed to one built through the official channels. It’s intended to differentiate between a user-built version and an officially-provided version, which might have subtle differences in code, according to when it was checked out and to what tag(s). Perhaps makepanda isn’t aware of this convention.

The symbol Py_InitModule4_64 is certainly a Python symbol. The fact that it is asking for it, and not finding it, suggests that the version of Python that you had compiled Panda against is not the same version of Python that you are now using to run Panda. Is this possible?

David

29

Heh, thanks, I won’t :slight_smile: I have still ppremake to try in case this last 0.1% will not be solved.

Is there a way to tell makepanda which Python to use? I do indeed have both 2.4 and 2.5 from Debian - but no idea which one is being used when I issue makepanda/makepanda. Just running “python” gives me 2.4, only when I run python-2.5 it is the 2.5 one. I will try changing some symlink so it always is 2.5 and try re-building.

(Also, as suggested by someone further up in this thread, I had to add that missing symbol manually to some file - in case it matters.)

30

I see, that’s a bug in makepanda. It should test your system-standard python interpreter (/usr/bin/python) to see which one it is, and compile against that.

You may have to alter a few lines in makepanda to force it to choose the right version of python. Search around in there for where it sets the variable PYTHONSDK. You might have to alter the code that sets that variable.