Demo Linking problems on Linux w/ v2.12

[daBrado]

Hi,

I am trying to use Bullet v2.12 on a 64 bit Linux machine, but am not having much luck.

The libraries appear to build alright, but none of the example programs or my own program seem to be able to link against the Bullet libraries. However, on a G5 running Mac OS X I am able to do both these things just fine.

For example, here is what happens when trying to build CcdPhysicsDemo:

Code: Select all

LinkApplication CcdPhysicsDemo

./out/linux/optimize/libs/libbulletopenglsupport.a(DemoApplication.o)(.text+0x2c80):
    In function `DemoApplication::mouseFunc(int, int, int, int)':
    : undefined reference to `btPoint2PointConstraint::btPoint2PointConstraint(btRigidBody&, btVector3 const&)'

./out/linux/optimize/libs/libbulletopenglsupport.a(GL_ShapeDrawer.o)(.text+0x6b5):
    In function `GL_ShapeDrawer::drawOpenGL(float*, btCollisionShape const*, btVector3 const&, int)':
    : undefined reference to `btStridingMeshInterface::InternalProcessAllTriangles(btInternalTriangleIndexCallback*, btVector3 const&, btVector3 const&) const'

collect2: ld returned 1 exit status

  g++ -o CcdPhysicsDemo ./out/linux/optimize/Demos/CcdPhysicsDemo/CcdPhysicsDemo.o  ./out/linux/optimize/libs/libbulletdynamics.a ./out/linux/optimize/libs/libbulletcollision.a ./out/linux/optimize/libs/libbulletopenglsupport.a ./out/linux/optimize/libs/libbulletmath.a -lglut -lGL -lSM -lICE -L/usr/X11R6/lib64 -lX11 -lXext -lpthread -lm -lGLU -lGL -lSM -lICE -L/usr/X11R6/lib64 -lX11 -lXext -lpthread -lm 

...failed LinkApplication CcdPhysicsDemo ...

Thank you for any help on this...

- Braden

[daBrado]

Oh, and this is the gcc version on the machine:

gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)

[Erwin Coumans]

Hi,

First of all, it looks like a linker error, not a compile error.
What build system are you using? CMake or jam?
I just verified the Jamfile build system, and the order of the libraries is wong.

g++ -o CcdPhysicsDemo ./out/linux/optimize/Demos/CcdPhysicsDemo/CcdPhysicsDemo.o ./out/linux/optimize/libs/libbulletdynamics.a ./out/linux/optimize/libs/libbulletcollision.a ./out/linux/optimize/libs/libbulletopenglsupport.a ./out/linux/optimize/libs/libbulletmath.a -lglut -lGL -lSM -lICE -L/usr/X11R6/lib64 -lX11 -lXext -lpthread -lm -lGLU -lGL -lSM -lICE -L/usr/X11R6/lib64 -lX11 -lXext -lpthread -lm

It looks like the linking order or not right. libopenglsupport.a needs to be included before libbulletdynamics.a.
CMakeLists.txt should have the order right, can you try CMake?

Code: Select all

LINK_LIBRARIES(
LibOpenGLSupport  LibBulletDynamics  LibBulletCollision LibLinearMath    ${GLUT_glut_LIBRARY} ${OPENGL_gl_LIBRARY} ${OPENGL_glU_LIBRARY}
)

The Jamfile in the demos have the ordering wrong, please move bulletopenglsupport before bulletdynamics in Demos/Jamfile and let me know if that solves the link problem.

Demos/OpenglSupport defines a shared DemoApplication that uses Bullet or mouse picking and rendering of the collision shapes etc.
Link order for the libraries is openglsupport, bulletdynamics, bulletcollision, bulletmath.

Can you download Bullet-2.12a.tgz and report if that fixes things?

Thanks for the feedback
Erwin

[daBrado]

First of all, it looks like a linker error, not a compile error.

Indeed...

What build system are you using? CMake or jam?

Jam

Should I be using CMake for building Bullet?

Demos/OpenglSupport defines a shared DemoApplication that uses Bullet or mouse picking and rendering of the collision shapes etc.
Link order for the libraries is openglsupport, bulletdynamics, bulletcollision, bulletmath.

Can you download Bullet-2.12a.tgz and report if that fixes things?

I did, and the demos seem to build just fine now (using Jam).

Did you want me to do any of the other things mentioned above (edit the Jamfile, try CMake)? Or does the fact Bullet-2.12a's demos build negate that need?

Also, I tried the above link order for my own program, and it also builds on the Linux machine. Thanks!

I don't understand though.. the previous link order for my program failed on Linux but worked on my Mac OS X machine. Does OS X's gcc v4.0.1 do something different in this regard?

Thanks again,
Braden

[Erwin Coumans]

I'm glad it fixed your problem. I just made the changes in Bullet 2.12a, so if that works you are fine.

Some linkers handle the forward/backward/cross-referencing of symbols automatically (doing a multi-pass approach etc), other linkers don't.

Apple's and Microsoft compiler handle it automatically, and so do some versions of GCC. it's best to not rely on it, and get the order right. Also, I made effort not to have circular dependencies, so no need to add libraries more then once.

Thanks,
Erwin

[daBrado]

Thanks for the info.

BTW, somewhat off topic though related to linking against Bullet libraries, when I link against bulletmath on OS X or Linux, I get something like this:

Code: Select all

/usr/bin/ld: warning empty table of contents: ./out/macosxppc/optimize/libs/libbulletmath.a (can't load from it)

Is this a problem?

- Braden

[Erwin Coumans]

no, it's not a problem. Unless you enable profiling (btQuickprof.h) there is no symbols in the library, it is all inline headerfiles.

You can safely ignore it.
I might add some large methods in a cpp, to avoid this warning.

Thanks,
Erwin

[SteveBaker]

no, it's not a problem. Unless you enable profiling (btQuickprof.h) there is no symbols in the library, it is all inline headerfiles.

You can safely ignore it.
I might add some large methods in a cpp, to avoid this warning.

Thanks,
Erwin

One of the other problems with empty libraries is that people using autoconf/automake can't easily detect whether the library is present or not. In your 'configure.in' file, you say things like:

AC_CHECK_LIB(GL, glBegin)

...which writes a little C/C++ program containing a glBegin() call and verifies that the program compiles and links OK against '-lGL'. However, this can only work if there is at least one function which is both guaranteed to be there and to *NOT* be 'inline'.

So what I've started doing with my libraries is to define a 'do nothing' function that's explicitly there for AC_CHECK_LIB to find - it's a great convenience to the end user to have such a function and because it's only used for this special purpose, it's continued existance through any number of generations of the library is assured. I always use the name of the library followed by the word 'Probe' - so (for example) my 'gameTools' library includes:

void gameToolsProbe () { } /* For autoconf/AC_CHECK_LIB - do not remove!! */