Environment Variable

[Guti]

hi,
i am having the same issue (win10_x64)
Qt Creator 4.9.1

did set the BULLET_PATH_ENVIRONMENT to "C:\bulletphysics\bullet3"

i am just trying to figure out the Qt 3D and bullet physics engine in order to get started with my own project

currently i am trying to compile this simulator:
https://github.com/patrickelectric/Qt3D-Konqi-Simulator

therefore I checked out this repository
https://bitbucket.org/csaga77/bullet-physics-qml-plugin/src/master/
into this folder:
Qt3D-Konqi-Simulator\lib\bullet-physics-qml-plugin

and here you can see my build settings

I am also getting the error message "bullet development package not found"

Can someone help me out?

[SGaist]

Hi and welcome to devnet,

Where did you set that environnement variable ?
Does it appear in your projet build and run environnements ?

[Guti]

@SGaist thank you for your quick response
I set the environment variable in the System variables via the System Properties

it appears in the Build Environment:

the Run Environment uses the Build Environment - so it also appears there

[SGaist]

Did you base your project on this .pri file ?

[aha_1980]

@Guti try to use forward slashed in paths.

\b is the backspace sequence and likely to fail.

Regards

[Guti]

thanks for your reply, but i stopped trying to compile this example
i checked out the bullet source code https://github.com/bulletphysics/bullet3
and compiled as described in the readme section: Build instructions for Bullet using premake.

• adapt python path in the .bat script file
• compiled it in MS Visual Studio

-> then the lib files were generated into the new folder

unfortunately I could not comile the example projects (i.e. HelloWorld) in Qt by linking the generated lib files
i'm not sure if this was because of compiler differencies in MSVS 2019 and Qt or just because of linking failures on my side...

Anyways, now we do it like here:
also include the needed .cpp files, not the best approach and it throws lots of warnings, but it's working...

my .proj file for the BulletHelloWorld example:

QT -= gui

CONFIG += c++11 console
CONFIG -= app_bundle

# The following define makes your compiler emit warnings if you use
# any Qt feature that has been marked deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS

# You can also make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

SOURCES += \
        main.cpp \
        $$PWD\bullet3\src\BulletCollision/BroadphaseCollision/*.cpp \
        $$PWD\bullet3\src\BulletCollision/CollisionDispatch/*.cpp \
        $$PWD\bullet3\src\BulletCollision/CollisionShapes/*.cpp \
        $$PWD\bullet3\src\BulletCollision/Gimpact/*.cpp \
        $$PWD\bullet3\src\BulletCollision/NarrowPhaseCollision/*.cpp \
        $$PWD\bullet3\src\BulletDynamics/Character/*.cpp \
        $$PWD\bullet3\src\BulletDynamics/ConstraintSolver/*.cpp \
        $$PWD\bullet3\src\BulletDynamics/Dynamics/*.cpp \
        $$PWD\bullet3\src\BulletDynamics/Vehicle/*.cpp \
        $$PWD\bullet3\src\LinearMath/*.cpp

HEADERS += \
    $$PWD\bullet3\src\BulletCollision/BroadphaseCollision/*.h \
    $$PWD\bullet3\src\BulletCollision/CollisionDispatch/*.h \
    $$PWD\bullet3\src\BulletCollision/CollisionShapes/*.h \
    $$PWD\bullet3\src\BulletCollision/Gimpact/*.h \
    $$PWD\bullet3\src\BulletCollision/NarrowPhaseCollision/*.h \
    $$PWD\bullet3\src\BulletDynamics/Character/*.h \
    $$PWD\bullet3\src\BulletDynamics/ConstraintSolver/*.h \
    $$PWD\bullet3\src\BulletDynamics/Dynamics/*.h \
    $$PWD\bullet3\src\BulletDynamics/Vehicle/*.h \
    $$PWD\bullet3\src\LinearMath/*.h

# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target

#win32: LIBS += -L$$PWD/bullet3/libs/ -lBulletDynamics_vs2010_x64_release -lBulletCollision_vs2010_x64_release -lLinearMath_vs2010_x64_release

INCLUDEPATH += $$PWD/bullet3/src
DEPENDPATH += $$PWD/bullet3/src

#win32:!win32-g++: PRE_TARGETDEPS += $$PWD/bullet3/libs/BulletDynamics_vs2010_x64_release.lib

unfortunately I can not upload the whole zipped project (~5MB), but I just copied the bullet3 folder from the repository into my Qt project

[aha_1980]

@Guti

$$PWD\bullet3\src\BulletCollision/BroadphaseCollision/*.cpp

Wrong. Path separator is forward slash in qmake. And as already said above, \b is a special char like \t and that will bite you.

[Guti]

ok, thank you - i will replace the backslashes, but I just want to mention:
this settting is working ;-)

[aha_1980]

@Guti said in Environment Variable:

this settting is working ;-)

Unfortunately this doesn't mean it is correct. And it can stop working from one day to another... so better fix it.

Regards

[8Observer8]

Build Bullet from source useing CMake GUI and MinGW. You will get libs (files with .a extension). Place "include" and "lib" folder in common folder, for example, in "Libs/Bullet"

Create an empty C++ project. Add these settings to .pro:

INCLUDEPATH += "E:\Libs\Bullet3-2.89\include"

LIBS += -L"E:\Libs\Bullet3-2.89\lib"
LIBS += -lBulletDynamics -lBulletCollision -lLinearMath

SOURCES += \
    main.cpp

Try to compile it:

main.cpp

#include <btBulletDynamicsCommon.h>

int main()
{
    btDefaultCollisionConfiguration *collisionConfiguration = new btDefaultCollisionConfiguration();

    return EXIT_SUCCESS;
}

It works.

[8Observer8]

But I found a very strange behavior. If I write like this:

LIBS += -lBulletCollision -lBulletDynamics -lLinearMath

I will get these errors:

btTypedConstraint.cpp:-1: error: undefined reference tobtCollisionObject::~btCollisionObject()'
btTypedConstraint.cpp:-1: error: undefined reference to btCollisionObject::~btCollisionObject()' btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::btCollisionObject()'
btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::btCollisionObject()' btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::serialize(void*, btSerializer*) const'
btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::~btCollisionObject()' btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::~btCollisionObject()'
btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::~btCollisionObject()' btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::~btCollisionObject()'
btRigidBody.cpp:-1: error: undefined reference to btCollisionObject::~btCollisionObject()'

But if I change the order of libs it works correctly:

LIBS += -lBulletDynamics -lBulletCollision -lLinearMath

[JonB]

@8Observer8
Does BulletDynamics reference something in BulletCollision? The order of library linking is significant.

[safylee]

@Guti have you solve the probem? I met the same trouble.The bullet package not found!

[Guti]

@safylee I did not solve it for this example project, but as I mentioned in a later comment, I could make the bullet engine work with my own project.

[8Observer8]

@JonB said in Environment Variable:

The order of library linking is significant.

Yes, I set this order of libraries and it works:

LIBS += -lBulletDynamics -lBulletCollision -lLinearMath

[JonB]

@8Observer8
Indeed, so it does. What do you find "a very strange behavior"? It is working as expected. Libraries expect to find other Libraries which resolve the first one's undefined references later on the linker line. If they came earlier the linker would not know they were needed by a later library.

[8Observer8]

@JonB said in Environment Variable:

Indeed, so it does. What do you find "a very strange behavior"?

I didn't know before that the order of the libraries mattered, so I called it strange behavior, but now I know.

[JonB]

@8Observer8
Ah yes, OK. The linker processes its files once in a single pass, left to right (there is no "going back" leftwards). Only those modules in a library which resolve currently (i.e. at the instant they are encountered) wanted symbols are pulled into the target executable. Else it would have to include everything just in case it's wanted later, and that's not how libraries work. So basically arrange them with the "lowest level" libraries to the right.