I don't doubt the Bullet source code is "correct". I meant I should check if the call in question is surrounded by #ifdefs or something similar which would explain why that one symbol is missing, maybe I am compiling it wrong. I am quite sure my building or linking to Bullet is to blame here...
I should also add that I have almost no first-hand experience building for anything other than Windows. Anyway, this will have to wait until my current task is done.
Try playing with adding -Wl,--whole-archive to the LDFLAGS when building the bullet DSO. You're only doing partial linking when you're building your plugin, and the linker doesn't see the static object being used outside the library so it gets left behind in the static library. You need to tell the linker to put all of what's in the archive into the dynamic library. Creating shared libraries from static archives is tricky, that's why most build tools are a little goofy when dealing with that.
Allright, I actually got it working, but I am not sure why it didn't work yet. So, I had a look at the problematic call, and as I suspected it was surrounded by #ifdefs (usually profiling code like this can be compiled out).
#ifndef BT_NO_PROFILE
CProfileManager::Reset();
#endif //BT_NO_PROFILEAll I did was make sure BT_NO_PROFILE was defined when compiling both the plugin library and bullet itself. Not sure why I would have to do this though, as I have used the exact same way of building everything on OSX and Windows. But it works and that's the most important thing.
CMake is more than capable of handling the build configuration you describe, provided that the target dependencies have been correctly declared. The two most likely causes of your issue are 1) libLinearMath.a isn't being linked in (however this would probably result in a lot of other unresolved symbols), or 2) libLinearMath.a is being linked in before whichever object uses the symbol. Either way, it points to a fixable configuration problem.
Is the code that calls CProfileManager::Reset() inside a translation unit that's linked directly into the shared library, or is it in another static library (or perhaps shared library)? How have you configured your target dependencies (i.e. [TARGET_]LINK_LIBRARIES)? Also next time you build, use "make VERBOSE=1" for it to echo all the commands it executes so you can observe the link line it generates.
On 10/17/2018 at 4:27 PM, GuyWithBeard said:Allright, I actually got it working, but I am not sure why it didn't work yet. So, I had a look at the problematic call, and as I suspected it was surrounded by #ifdefs (usually profiling code like this can be compiled out).
And there is no options to enable this when configuring the build (./configure --help might give your some hints if the project uses autoconf, and config.h is the file where all enabled options get their defines set) ?
