Errors linking against libs from trunk

[Kevin Godby]

Hello.

I'm getting the following errors when I try to link against the new osgbullet libraries.  I'm guessing I've done something stupid, but haven't figure out what it is yet.  Any ideas? 

The follow errors occur when osgbullet tries to build its tests:

../../lib/libosgbDynamics.so.1.01.82: undefined reference to `btStaticPlaneShape::btStaticPlaneShape(btVector3 const&, double)'

../../lib/libosgbCollision.so.1.01.82: undefined reference to `btConvexHullShape::btConvexHullShape(double const*, int, int)'

../../lib/libosgbCollision.so.1.01.82: undefined reference to `btShapeHull::buildHull(double)'

Thanks for any help!

--Kevin Godby

[Paul Martz]

Hi Kevin -- I'm not seeing these issues.

Have you tried a clean rebuild?

Have you tried deleting your CMake cache and regenerating the makefiles? The dev
on trunk has been quite dramatic, so this is probably required.

What do you have CMAKE_CONFIGURATION_TYPE set to? I have been leaving this blank
on Linux / OS X builds.

I've been doing my dev solely with Bullet 2.78, but I'd think 2.76 and 2.77
should also define these symbols. What version of Bullet are you using?

Also, make sure you're using osgWorks trunk. That wouldn't cause these errors,
but is a requirement as we get closer to the 2.0 release.

Let me know how it goes.
-Paul

[Paul Martz]

Also, check to make sure CMake actually found Bullet. The osgBullet
FindBulletHelper.cmake script doesn't use the REQUIRED tag when it looks for
Bullet, so if it fails to find it, you still get project makefiles -- but Bullet
libraries won't be on your link line.

To check, select "advanced" in cmake-gui and look at BULLET_DYNAMICS_LIBRARY's
value.

I am installing Bullet 2.78 (rather than trying to use it out of a source/build
tree or alternate install location), and osgBullet's CMake system is able to
find Bullet easily when I do this.

(We might need to fix this and use the REQUIRED tag, but I have a feeling this
isn't as simple as just adding the REQUIRED tag to the find_package call...)
-Paul

--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/

[Kevin Godby]

Hello, Paul.

On Fri, Sep 2, 2011 at 8:25 AM, Paul Martz <pma...@skew-matrix.com> wrote:
> Hi Kevin -- I'm not seeing these issues.
>
> Have you tried a clean rebuild?

I just removed the osgbullet files and checked out a fresh copy from svn.

> Have you tried deleting your CMake cache and regenerating the makefiles? The
> dev on trunk has been quite dramatic, so this is probably required.

Yep.

> What do you have CMAKE_CONFIGURATION_TYPE set to? I have been leaving this
> blank on Linux / OS X builds.

The build type is an empty string.

> I've been doing my dev solely with Bullet 2.78, but I'd think 2.76 and 2.77
> should also define these symbols. What version of Bullet are you using?

I'm building against Bullet 2.78 as well.

> Also, make sure you're using osgWorks trunk. That wouldn't cause these
> errors, but is a requirement as we get closer to the 2.0 release.

I am using trunk, though it may be lagging a couple days at this point.

On Fri, Sep 2, 2011 at 9:18 AM, Paul Martz <pma...@skew-matrix.com> wrote:
> Also, check to make sure CMake actually found Bullet. The osgBullet
> FindBulletHelper.cmake script doesn't use the REQUIRED tag when it looks for
> Bullet, so if it fails to find it, you still get project makefiles -- but
> Bullet libraries won't be on your link line.
>
> To check, select "advanced" in cmake-gui and look at
> BULLET_DYNAMICS_LIBRARY's value.

It looks like it did. I've attached the CMakeCache.txt file so you
can skim through and see if anything's amiss.

What's the purpose of the helper scripts? They were unsetting the
bullet locations that I had set on the command line and I had to poke
through the cmake scripts to see what was happening.

I've been running cmake with the following command line: cmake ..
-DCMAKE_INSTALL_PREFIX=$HOME/vtdeps
-DBULLET_INCLUDE_DIR=~/vtdeps/include/bullet
-DBulletInstallType="Alternate Install Location"
-DBulletInstallLocation=~/vtdeps -DOSGBULLET_BUILD_APPLICATIONS=0
-DOSGBULLET_BUILD_EXAMPLES=0 -DOSGBULLET_USE_DOUBLE_PRECISION=1
-DOSGInstallType="Alternate Install Location"
-DOSGInstallLocation=~/vtdeps -DCMAKE_PREFIX_PATH=~/vtdeps
-DOSGBULLET_BUILD_TESTS=1

Thanks for your help!

--Kevin

[Paul Martz]

On 9/2/2011 10:40 AM, Kevin Godby wrote:
> It looks like it did. I've attached the CMakeCache.txt file so you
> can skim through and see if anything's amiss.
>
> What's the purpose of the helper scripts? They were unsetting the
> bullet locations that I had set on the command line and I had to poke
> through the cmake scripts to see what was happening.
>
> I've been running cmake with the following command line: cmake ..
> -DCMAKE_INSTALL_PREFIX=$HOME/vtdeps
> -DBULLET_INCLUDE_DIR=~/vtdeps/include/bullet
> -DBulletInstallType="Alternate Install Location"
> -DBulletInstallLocation=~/vtdeps -DOSGBULLET_BUILD_APPLICATIONS=0
> -DOSGBULLET_BUILD_EXAMPLES=0 -DOSGBULLET_USE_DOUBLE_PRECISION=1
> -DOSGInstallType="Alternate Install Location"
> -DOSGInstallLocation=~/vtdeps -DCMAKE_PREFIX_PATH=~/vtdeps
> -DOSGBULLET_BUILD_TESTS=1

The Find*Helper.cmake scripts support a pulldown menu in cmake-gui that allows
you to switch relatively easily between standard install, alternate install, and
source/build tree. This is something I imagine most developers will want to do
at some point, and the plain CMake scripts really don't support this gracefully
at all.

Off the top of my head, I don't know the make option that causes all the
compile/link command lines to be echoed to the console; by default they're
hidden. But it would be really useful if you could clean and rebuild using this
option and post the full output. Make sure to build with 1 thread (-j1) to make
the output easier to read.

I'd also like you to try changing your setting of OSGBULLET_BUILD_EXAMPLES to 1;
this will build the collision-only example, and whether that encounters link
errors or not might shed some light on the issue.
-Paul

[Kevin Godby]

On Fri, Sep 2, 2011 at 7:19 PM, Paul Martz <pma...@skew-matrix.com> wrote:
> The Find*Helper.cmake scripts support a pulldown menu in cmake-gui that
> allows you to switch relatively easily between standard install, alternate
> install, and source/build tree. This is something I imagine most developers
> will want to do at some point, and the plain CMake scripts really don't
> support this gracefully at all.

Ah, I see. Usually in my cmake scripts, I add a variable that is
passed along as a hint to the search paths for libraries and includes.
In my FindBullet.cmake script, for instance, you can set
BULLET_ROOT_DIR to be the prefix you installed bullet to. I don't
know if this is optimal or even a good way to handle things—I'm a
cmake newbie—but it's worked for my projects so far.

> Off the top of my head, I don't know the make option that causes all the
> compile/link command lines to be echoed to the console; by default they're
> hidden. But it would be really useful if you could clean and rebuild using
> this option and post the full output. Make sure to build with 1 thread (-j1)
> to make the output easier to read.

It's 'make VERBOSE=1'. I've attached a log of the output.

> I'd also like you to try changing your setting of OSGBULLET_BUILD_EXAMPLES
> to 1; this will build the collision-only example, and whether that
> encounters link errors or not might shed some light on the issue.

In your examples/CMakeLists.txt file, you have a case-sensitivity
issue. 'BasicDemo' should be 'basicdemo' so that it matches the case
of the directory name. (I'm on Linux, so things are case-sensitive.)

I also had to manually set the BULLET_INCLUDE_DIR as it wasn't
detected automatically for some reason.

After correcting that, the examples failed to compile and gave the
same linker errors.

--Kevin

[Paul Martz]

On 9/2/2011 6:45 PM, Kevin Godby wrote:
> In your examples/CMakeLists.txt file, you have a case-sensitivity issue.
> 'BasicDemo' should be 'basicdemo' so that it matches the case of the directory
> name. (I'm on Linux, so things are case-sensitive.)

I'll take the blame for that. Now fixed.

I'm using gcc 4.2.1 on OS X. What version are you using? I'm wondering if you
have a different version which is somehow more sensitive to the function
signatures, though it seems like, if this were the issue, we would've seen
compile errors/warnings before the link.

Anyhow, not seeing anything else amiss, I changed the code slightly to ensure
osgBullet's calls matched the Bullet header signatures. Please update and try
again. I hope this helps.

Thanks for being patient and working with me on this while I try to debug remotely.
-Paul

[Kevin Godby]

Hello, Paul.

After spending more time than I'd care to admit tracing symbol names
through the source code and libraries of both bullet and osgbullet, I
finally figured out what the problem was.

I had told osgbullet that I had compiled bullet using double
precision. This was a lie.

So the missing symbols were because of a mismatch between doubles/floats.

To save myself all this embarrassment (and both of us some time) in
the figure, I wonder if we shouldn't just check to see whether bullet
was actually compiled with doubles or floats instead of relying on the
(in this case, stupid) person compiling osgbullet to know.

I've created a short test-bullet-precision program (attached). It
appears to work okay for my simple tests. Feel free to take it,
modify it, use it, or simply discard it. We could probably
incorporate it into a FindBullet.cmake script or your Bullet helper
cmake script.

After telling osgbullet that bullet wasn't using double precision and
recompiling, the osgbullet libraries and examples both successfully
compiled.

Thanks again for all your help!

--Kevin

[Paul Martz]

Yeah, double precision, that would do it.

You know, OSG used to have a similar problem. OSG lets you set single vs double
precision for the vector, matrix, and bounding volumes in CMake. It used to be
just like Bullet, setting a -D on the command line, so when you built an
external project, you had to ensure you used the same definitions as was used to
build OSG, otherwise things wouldn't link.

Around OSG v2.4 (I think?) OSG changed so that CMake generated a header file,
osg/Config, which contained all those CPP definitions, so external projects
could just #include <osg/Config> and not have to worry about it.

While that change sounds good, at the time it broke a lot of external projects
that were set up to build against OSG from a source and build tree, and had a -I
only for the source tree. They would fail to compile with numerous "unable to
find header osg/Config" errors. All the broken external projects had to either
switch to using an installed OSG, or modify their build environment to add a -I
for the build tree's include directory. It was a painful change.

I doubt the Bullet project managers would approve of the OSG solution. I believe
they don't even use the CMake infrastructure to build Bullet. That's a pretty
big strike against adopting such a change.

Thanks for posting the program. I'm not going to do anything about this
immediately, but I would like to hear the input of others on different ways to
handle this. Is there a way for osgBullet's CMake to automatically determine if
Bullet is built for double precision or not, for example?
-Paul

[Karrot]

If you have built Bullet yourself, the CMakeCache.txt in your build
dir has a

//Use double precision
USE_DOUBLE_PRECISION:BOOL=OFF

Im not too fermiliar with cmake, but there should be a way to scan a
simple text file for a string, and use that to build osgBullet
accordingly.
There might be another way, but i wouldn't know how. The above is
fairly limited obviously as it would only work in that specific case.

Bullet-C-Api.h contains the check for the BT_USE_DOUBLE_PRECISION btw,
but is also present in ~11 other headers as checks. I doubt the built
files will be able to be used to distinguished between using double
precision.

[Paul Martz]

Thanks, Kevin -- I've added your Bullet precision test app to the osgBullet
'extras' directory. I've also updated the osgBullet wiki with a "Troubleshooting
Builds" section describing this issue and pointing people to that test app.

CMake does have a exec_process command, so if there's some way to execute some
cross-platform tools that could indicate Bullet's precision with a return value,
we could build this into osgBullet's CMake.

If there are no cross platform tools to do this (and I can't think of any), then
it seems like the best approach would be to contribute your test app to the
Bullet project. Then, once our CMake finds Bullet, it could exec_process that
test app to get the precision. I'll add this to my to-do list.

Karrot, I looked into your idea of parsing the Bullet CMake cache directly in
CMake. It's possible, but it's more CMake dev than I can pursue right now, and
as you already said it's just a partial solution for people using Bullet they
built themselves, and built with CMake.
-Paul

On 9/3/2011 11:11 PM, Kevin Godby wrote:

[Kevin Godby]

Hey, Paul.

On Sun, Sep 11, 2011 at 9:55 AM, Paul Martz <pma...@skew-matrix.com> wrote:
> Thanks, Kevin -- I've added your Bullet precision test app to the osgBullet
> 'extras' directory. I've also updated the osgBullet wiki with a
> "Troubleshooting Builds" section describing this issue and pointing people
> to that test app.
>
> CMake does have a exec_process command, so if there's some way to execute
> some cross-platform tools that could indicate Bullet's precision with a
> return value, we could build this into osgBullet's CMake.
>
> If there are no cross platform tools to do this (and I can't think of any),
> then it seems like the best approach would be to contribute your test app to
> the Bullet project. Then, once our CMake finds Bullet, it could exec_process
> that test app to get the precision. I'll add this to my to-do list.

I don't think my test program does quite what I'd like, actually.
Since it's just including the bullet header, the program is really
only reflecting whether or not you've set BT_USE_DOUBLE_PRECISION
*when you compiled the test program*.

Instead, we should write a test program that tries to link against the
bullet library. If it links successfully using double instead of
float, then double precision was used to compile the bullet libraries.
(Basically, we want to deliberately invoke and detect the errors that
started this whole thread. If the errors exist, then there's a
mismatch between the test program's precision and the precision
compiled into the bullet libraries.)

--Kevin

[Paul Martz]

On 9/11/2011 3:23 PM, Kevin Godby wrote:
> Hey, Paul.
>
> On Sun, Sep 11, 2011 at 9:55 AM, Paul Martz<pma...@skew-matrix.com> wrote:
>> Thanks, Kevin -- I've added your Bullet precision test app to the osgBullet
>> 'extras' directory. I've also updated the osgBullet wiki with a
>> "Troubleshooting Builds" section describing this issue and pointing people
>> to that test app.
>>
>> CMake does have a exec_process command, so if there's some way to execute
>> some cross-platform tools that could indicate Bullet's precision with a
>> return value, we could build this into osgBullet's CMake.
>>
>> If there are no cross platform tools to do this (and I can't think of any),
>> then it seems like the best approach would be to contribute your test app to
>> the Bullet project. Then, once our CMake finds Bullet, it could exec_process
>> that test app to get the precision. I'll add this to my to-do list.
> I don't think my test program does quite what I'd like, actually.
> Since it's just including the bullet header, the program is really
> only reflecting whether or not you've set BT_USE_DOUBLE_PRECISION
> *when you compiled the test program*.

Very good point! However, it seems like if your test program is part of the
Bullet project and installed with the Bullet libs, then presumably it's built
the same way as Bullet. When osgBullet's CMake finds that test exe and runs it,
we should have all the info we need. The downside, of course, is we're looking
at a solution only for Bullet 2.79 and forward...

> Instead, we should write a test program that tries to link against the
> bullet library. If it links successfully using double instead of
> float, then double precision was used to compile the bullet libraries.
> (Basically, we want to deliberately invoke and detect the errors that
> started this whole thread. If the errors exist, then there's a
> mismatch between the test program's precision and the precision
> compiled into the bullet libraries.)

You are correct, this would be more robust. We might be able to do this with
CMake, as it has already found the compiler. Maybe a good dig through CMake's
initial configuration scripts would produce an example of how to perform this step.
-Paul

[Paul Martz]

Hey Kevin -- Good news. I got this working this afternoon and have
checked it in on trunk. It is not in the recent 2.0 release.

It uses the CMake try_compile command to do exactly as you describe.
The try_compile command is invoked from the FindBulletHelper.cmake
script anytime it needs to search for Bullet and successfully finds
it.

This means the CMake flag in the cmake-gui to specify double precision
is no longer present (unless you have it in your cache) or used. For
anyone building on trunk, please give this a try by deleting your
cache and re-building in CMake. You should see output in the cmake-gui
window when it checks for double precision, and whether it decided
that Bullet was using it or not.

The small test program that gets compiled is in the CMakeModules
directory. If it fails to compile even though you know you're using
double precision, post here and we'll try to work out the issue.
-Paul

[Kevin Godby]

On Thu, Oct 27, 2011 at 4:09 PM, Paul Martz <pma...@skew-matrix.com> wrote:
> Hey Kevin -- Good news. I got this working this afternoon and have
> checked it in on trunk. It is not in the recent 2.0 release.

Excellent! I always appreciate it when software prevents me from
making stupid mistakes!

Congratulations on the 2.0 releases of osgBullet and osgWorks, too.

--Kevin