SOLVED: ...ode... installed but does not export symbol.

Installation
1

Hello again.

I’m now trying to build the CVS version of Panda3D. The build is 92% done, when it hangs with this fatal message:

ImportError: /home/dirk/Desktop/My_Programs/panda3d/built/lib/libpandaode.so: undefined symbol: dGeomTriMeshIsTCEnabled

I have the packages python-pyode and python-pyode-doc installed, and have seen my ODE system (version 0.11.1) functioning with other software.

Can somebody tell me what’s going wrong here?

Dirk

P.S. Installing any other version of ODE, in my experience, breaks OGRE.

P.S.S. There’s another detail about my system, which I may as well admit to. As belonging to the Debian/Etch repository, my ‘normal’ ODE version would be 1:0.5.dfsg-2 , and my normal pyode version would be 1.1.0-1 . Yet some of you might notice that these version numbers are just not high enough to support major software. Thus, I do custom compiles.

But, when we install software via custom compiles, the Debian package manager does not usually register this software as installed, because it tracks packages themselves rather than software. And this means, that if I have packages to install with the ‘libode0c2’ runtime as their dependency, those will subsequently fail to install, due to my compiled install of ODE.

Therefore one trick which I rarely but sometimes do use, is to keep the packages installed, and then to do a ‘make install’ on top of the files that first belonged to the packages. I know that in some cases this can result in (pseudo-)packages that stop working, in which case I need to remove the package first, and then ‘make install’ again. Yet I felt that with ODE I pretty much got away with that so far, and one factor for which I might have, would be that the custom compile of ODE does not put the files into any different directory paths. Usually, if I had packages that installed to /usr/lib , and a compiled install to /usr/local/lib, then this would be enough to prevent this trick from working.

I call this ‘a primitive overlay’ of files, because that is what it is in individual directories.

But with Etch, I’m screwed if I can’t do this, because (1) I do have dependent packages which insist that they want to see their other packages, and (2) Etch does not allow me to put sufficiently high version numbers as packages, to allow OGRE, Panda3D and so on to work.

But in this one case, I’m more worried about the ‘installed’ package ‘libode0-dev’ than I am about ‘libode0c2’ itself. And my reason is the description in the package manager, according to which the ‘…-dev’ package does not just include header files, but also static libraries . The kind of linking error that I’m getting from Panda3D, is firstly warning me that objects were originally defined in a different location than the correct one, which gets ignored as the compile continues, and then suggests that a static library was embedded in the generated .so file, which is failing to link to another shared library.

I would guess at this point, that most of you are not getting this warning either, which I can’t reproduce for the moment, but which reads “…originally defined here:”

But (1) OGRE seems to allow me to run Physics demos successfully, and (2) if I can never do an overlay like this under Debian/Etch, the result remains that I cannot install Panda3D anyway. It wouldn’t really help to find this out. Further, if I was just to uninstall the package ‘libode0-dev’ right now, this would also rip out any static libraries and header files which my custom compile overlaid into the same directories.

I do keep track for which (pseudo-)packages I did this, in the directory on my system where I keep many individual source trees.

And still, does anybody have helpful hints about this?

2

Sorry to bump my thread. But I believe that this is an issue on my setup, which looks like a complete mess, but which really shows promise of being resolved in a few days.

Unlike my first assumption, which I stated in my post above, it is true that the package installs to /usr/lib , while the custom compile installs to /usr/local/lib . But this may save the day.

Within /usr/lib , I found a symlink named ‘/usr/lib/libode.so’ which points to ‘/usr/lib/libode.so.0’ . I’ve convinced myself that this is my main problem with ODE right now, because this symlink points to the default version, which belongs to package ‘libode0c2’ even according to the package manager, and the default version may simply not have many of the symbols defined, which later versions are to have. Unfortunately, I have not found a shared library under /usr/local/lib, that also corresponds to libode.so . If I had, I might have changed the symlink by now, by hand.

But what may have happened, is that the compiled version of ODE, 0.11.1 , may have installed the static libraries and header files, but not any shared library. And I don’t know where within the ODE source tree the shared library would be found. Failing to find out this information soon, I might want to look into how to use ‘ode-config’ and ‘libtool’, both of which exist within my source tree, differently from the ones within /usr/lib . And just using the ODE libtool program, might already override this symlink to a newer version.

Anyhow the only goal for the moment, is to provide one shared library that can do what the include files declare. And if I have any luck with that, I shall let you know on this forum.

And BTW, I am ‘one of those boring older guys’, who have too many things to do each week, to spend as much time in front of my Box as I’d like to. :slight_smile:

Dirk

P.S. I believe that this would make a lot of sense, because when I built OGRE, I vaguely recall building that against the static libraries for ODE, not the shared libraries. And my reason would have been, that I wouldn’t want my eventual OGRE projects to have runtime dependencies on ODE packages supplied by potential recipients of my projects. I’d like to be able to build stand-alone projects as often as possible.

Which I suppose is about to change with Panda3D…

3

Update: I have learned, that by using --enable-shared with the ODE ./configure script, I can get it to generate shared libraries. But the lack of one earlier, does not seem to explain the error message I still get trying to build Panda3D.

My ODE libraries, both static and dynamic, are now installed in /usr/lib, and again, identically, in /usr/local/lib .

Okay, but these are the (unchanged) error messages I get:

python makepanda/makepanda.py --everything
WARNING: Could not locate thirdparty package artoolkit, excluding from build
Couldn’t find library libFColladaD
Couldn’t find library libFColladaSD
WARNING: Could not locate thirdparty package fcollada, excluding from build
WARNING: Could not locate thirdparty package fftw, excluding from build
WARNING: Could not locate thirdparty package fmodex, excluding from build
WARNING: Could not locate thirdparty package opencv, excluding from build
WARNING: Could not locate thirdparty package squish, excluding from build
WARNING: Could not locate thirdparty package vrpn, excluding from build
WARNING: Could not locate thirdparty package tinyxml, excluding from build
Generating dependencies…
[ 92%] Generating ‘pandac’ tree
Importing code library: libpandaexpress
Found extensions for class: Ramfile
Found extensions for class: StreamReader
Found extensions for class: HTTPChannel
Importing code library: libpanda
Found extensions for class: NodePath
Found extensions for class: Mat3
Found extensions for class: NodePathCollection
Found extensions for class: VBase3
Found extensions for class: VBase4
Importing code library: libpandaphysics
Importing code library: libpandafx
Importing code library: libp3direct
Found extensions for class: CInterval
Importing code library: libpandaskel
Importing code library: libpandaegg
Found extensions for class: EggPrimitive
Found extensions for class: EggGroupNode
Importing code library: libpandaode
Traceback (most recent call last):
File “direct/src/ffi/jGenPyCode.py”, line 94, in ?
DoGenPyCode.run()
File “/home/dirk/Desktop/My_Programs/panda3d/built/direct/ffi/DoGenPyCode.py”, line 302, in run
generateNativeWrappers()
File “/home/dirk/Desktop/My_Programs/panda3d/built/direct/ffi/DoGenPyCode.py”, line 258, in generateNativeWrappers
Dtool_PreloadDLL(moduleName)
File “/home/dirk/Desktop/My_Programs/panda3d/built/direct/extensions_native/extension_native_helpers.py”, line 79, in Dtool_PreloadDLL
imp.load_dynamic(module, pathname)
ImportError: /home/dirk/Desktop/My_Programs/panda3d/built/lib/libpandaode.so: undefined symbol: dGeomTriMeshIsTCEnabled
Storing dependency cache.
Elapsed Time: 2 sec

Build terminated.
make: *** [all] Error 1

One question I could really use an answer to, is 'Why is Panda3D using “Dtool_PreloadDLL”, on a Linux configuration? And I could use some further help at this point.

Dirk

4

It might strike some people as silly, if nobody was able to suggest a solution to me, that I’m still willing to post the solution I found myself. But the way I think, is that some other person might run into the same problem, and might find this solution.

That other person would also need to be facing the limitations of a Debian distribution such as Etch, and would also be plagued with often having to do custom compiles.

It turns out that this problem was, after all, caused by the fact that my primitive overlay of library files from a package, with library files resulting from a custom compile, caused confusion to code which needed to link to those libraries.

The real source of the confusion arose, because the original package’s libraries were installed to /usr/lib , but that the attempted overlay was not really an overlay at first, installing the newer libraries to /usr/local/lib . Thus, to tell ODE 0.11.1 to install its libraries to the same directory as the package manager already put its version in, was the solution itself.

The custom compile tends to put header files, which state greater capabilities than the code from repositories had, into the normal directories for header files. But then when linking, the build process will stumble across one version of the library before the other, basically according to chance. If the first file it runs across does not export the correct symbols, the build process generates erroneous results, and does not check for possible other versions of the library file. After all, there is really only supposed to be one version of that file.

The reason I could not see the change this made to compiling Panda3D at first, was the fact that I had forgotten to clear all the files into which the Panda3D source code had already been compiled. Thus, by issuing “rm -rf built” , I finally told Panda3D’s source tree to rebuild everything.

And now I have Panda3D compiled successfully, and installed! :smiley:

So the future exercises will be in learning how to use Panda3D.

Dirk

5

Hooray! I’m glad you found the solution.

To answer your question:

Simply because there’s no reason to avoid doing so, and this means we have one bit of code that can run the same way on all platforms. It’s true it’s not necessary on Linux, but it doesn’t do any harm either.

David

6

We could add a check if the dynamic library extension is in imp.get_suffixes(), and if so, import it normally - but the difference is zero.

(But actually, the new panda3d.* import system does avoid importing the module via imp.load_dynamic if it can be loaded normally.)