Building bullet-native on Windows – oh, no!

Hello!



It’s been quite a while since I’ve last used JME3, was in the process of porting over a work in progress …but life does often seem to have a way of getting in the way of games programming!



Anyway, I see there has been a decent amount of progress on features in the jme physics api, so kudos :slight_smile:



I’ve been trying to build bullet & native-bullet via the build script under nbproject, doesn’t work with mingw and cmake on Windows anymore. Problem looks to be down to Cmake failing to create correct makefiles for bullet (also described as such in the recent version of the bullet manual).

Luckily bullet has Visual Studio project files, so the bullet libs can be built that way.



Q) What the current build process for the windows natives, for both the bullet & jme’s bullet-native?

1 Like

I suggest to follow the readme included (somewhere in bullet/native in jme3), and NOT to use the visualstudio stuff (since then you get additional external dependencies on vc++ redist runtimes and such ****)



The Readme included works but under windows it is a bit complicated to get mingw and gcc to run correctly. However once this is done the rest is mostly copy pasting commands from the readme. I suggest to use the powershell instead of cmd (if aviable), as it is much more comfortable.

The process is embedded in the normal build script, I guess you started it from there? I didn’t change much about the windows part really, no idea why its not working. Afaik I had to do some small CmakeLists adaptions in the buller source to compile it properly though. Most interesting would be compiling with mingw on linux for windows 64.

Oh before I forget!

USE THE BULLET VERSION 2.72, as there are some api changes in the later ones and you would have to fix the wrapper to use them. (You are invited to do so, but I guess you just want to get taht wrapper stuff first to work anyway)

The build script automatically downloads the needed bullet version and it runs fine on my 64bit windows 7 computer with command line ant…

So it turns out that one my settings I’d chosen to receive notifications …d’oh! …and now that’s corrected



Thanks for the responses guys.



The script works fine upto building bullet, there is a problem in the makefiles generated by cmake, the compile tried to use a directory which isn’t created (but a directory with that name and a .dir suffix is created, which could be a simple variable problem in the makefile).



This problem was encountered when using mingw64, then uninstalled that and tried mingw32 - where both had the same problem, failing on bullet build.



So, if VS C++ is to be avoided, it sounds like the simplest solution is just to correct the makefiles for the bullet build and running with CMake & Mingw64 …might even try out powershell :wink:



I’ll give this a shot again tomorrow & keep you posted!

Right, found the time and this time made a note of what happened, just in case it’s of use to someone else down the line!



MinGW64 (64 bit)

After setting up MinGw64 (adding the bin folders to %PATH%) this:





C:DataDevelopmentjme3nbproject>ant -f build-bullet-natives.xml build-bullet-natives

Buildfile: C:DataDevelopmentjme3nbprojectbuild-bullet-natives.xml



create-native-headers:



-check-conditions-pre:



-get-bullet-sources:

[echo] Downloading bullet source…

[get] Getting: http://bullet.googlecode.com/files/bullet-2.79-rev2440.zip

[get] To: C:DataDevelopmentbullet.zip

[unzip] Expanding: C:DataDevelopmentbullet.zip into C:DataDevelopment

[delete] Deleting: C:DataDevelopmentbullet.zip



-compile-bullet-sources-windows:

[exec] CMake Error: CMake was unable to find a build program corresponding to “MinGW Makefiles”. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.

[exec] CMake Error: CMake was unable to find a build program corresponding to “MinGW Makefiles”. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.

[exec] CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.

[exec] Missing variable is:

[exec] CMAKE_C_COMPILER_ENV_VAR

[exec] CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.

[exec] Missing variable is:

[exec] CMAKE_C_COMPILER

[exec] CMake Error: Could not find cmake module file:C:/Data/Development/bullet-2.79/CMakeFiles/CMakeCCompiler.cmake

[exec] CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.

[exec] Missing variable is:

[exec] CMAKE_CXX_COMPILER_ENV_VAR

[exec] CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.

[exec] Missing variable is:

[exec] CMAKE_CXX_COMPILER

[exec] CMake Error: Could not find cmake module file:C:/Data/Development/bullet-2.79/CMakeFiles/CMakeCXXCompiler.cmake

[exec] CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage

[exec] CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage

[exec] – Configuring incomplete, errors occurred!



BUILD FAILED

C:DataDevelopmentjme3nbprojectbuild-bullet-natives.xml:497: exec returned: 1





As far as understanding goes, this is variable related, although I’m unsure where cmake define these variables.

There also is no mingw-make in the MinGW64 binary release …which will probably also cause problems.





MinGW (32 bit)

After setting up the MinGW from the latest Windows get installer, checking that the bin folder is on %PATH%:



Everything worked - no problem!



(Must have messed up when trying MinGW 32 last time, but that was the version I remember working before :wink: )





Question) Windows release for the Java 64bit JRE, how is it created? Should probably start by asking is there one?

There is none, its still being a bitch on linux with mingw as well as windows with mingw. VisualStudio worked for someone somehow sometime but we need mingw to work anyway to compile that on linux/mingw too. Its all in the build script but 64bit windows fails. Wasn’t it even you who posted this on the bullet forum back then? The issue hasn’t changed really, maybe you can find out more. I have a windows computer I can do testing on but no development really, its a touch pc ^^

Haha, yeah that post was mine …had completely forgotten about that.



Right, certainly clears things up for me, pretty sure I was thinking that the mingw64 was working outta the box, but no.



Having briefly looked into the mingw64 today, I’ve got a few more idea’s to try out, hoping it doesn’t get to the stage of compiling the source for it …but, we’ll see :cry:

Argh,…I recently fixed the Character<->Ghost collsion-problem and want this to be included

my native bullet for windows as well. BUUT I really can’t get it work. So sry to hijack this thread, but

it essentially goes in the same direction.



uh,…I have to say that I’m really frustated about building natives for windows.

Linux and MacOS worked out of the box, great. But with Windows I’m struggling since

the last 24h. I tried crosscompilation with linux(32bit) using the linux-bin for 32bit and 64bit

from here: http://sourceforge.net/projects/mingw-w64/files/ (Is this the right choice?).

That didn’t work. This was the first attempt and sry to say that I already forgot about the problem (since

the last time nothing worked and I lost the scope)



EDIT: I tested it again:

[java]-compile-bullet-sources-linux-mingw:

[exec] – The C compiler identification is unknown

[exec] – The CXX compiler identification is unknown

[exec] CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):

[exec] The C compiler “/usr/bin/i686-w64-mingw32-gcc” is not able to compile a

[exec] simple test program.

[exec]

[exec] It fails with the following output:

[exec]

[exec] Change Dir: /home/ttrocha/_dev/ex-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc

[exec] – Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc – broken

[exec] – Configuring incomplete, errors occurred!

[exec] tprojects/jme3/bullet-2.79/CMakeFiles/CMakeTmp

[exec]

[exec]

[exec]

[exec] Run Build Command:/usr/bin/make “cmTryCompileExec/fast”

[exec]

[exec] /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make

[exec] CMakeFiles/cmTryCompileExec.dir/build

[exec]

[exec] make[1]: Betrete Verzeichnis

[exec] ‘/home/ttrocha/_dev/extprojects/jme3/bullet-2.79/CMakeFiles/CMakeTmp’

[exec]

[exec] /usr/bin/cmake -E cmake_progress_report

[exec] /home/ttrocha/_dev/extprojects/jme3/bullet-2.79/CMakeFiles/CMakeTmp/CMakeFiles

[exec] 1

[exec]

[exec] Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj

[/java]





Then I switched to Windows. Using the same URL I grabbed the windows-binaries and mingw32-make

from here: http://sourceforge.net/projects/mingw/files/MinGW/Extension/make/mingw32-make-3.80-3/mingw32-make-3.80.0-3.exe/download (Right choice?)

I set the path to the bin-folder amd tried the ant-script with target build-bullet-natives

This ended up with a cmake-problem.(couldn’t compile a simple-program…)

Setting the cmake cxx and c paths helped for compiling bullet

[java]

<arg value="-DCMAKE_C_COMPILER=D:/dev/_downloads/UnxUtils/bin/i686-w64-mingw32-gcc.exe"/>

<arg value="-DCMAKE_CXX_COMPILER=D:/dev/_downloads/UnxUtils/bin/i686-w64-mingw32-g++.exe"/>[/java]

but struggeled for some headers when compiling the jni-gluecode.

(Not to mention my attempt using cygwin with normal Unix Makefiles instead of mingw…)



Lol,…time to start from the very beginning.

@monkey_scratches_head you seem to be able to compile it for 32bit. Any hints? Or a small summary of steps to take to properly get mingw setup. Or is there something like an introduction about compiling the natives I didn’T see yet?



Help would be very very appreciated.

…ok! I actually started over again! I finally made it. I used cross compiling with mingw under linux.

It worked with the mingw 32bit version. The ant-script assumes that the mingw is deployed under /usr

I didn’t know that…nevertheless it tried to access restricted areas (/root/…/include) Don’t know where and why

but using “sudo ant build-bullet-natives” worked for compiling bullet. Nevertheless I still had to specify the java-jni-includes.

Since I’m under linux I wasn’t sure if they are working for crosscompiliation,…and prevent the build script from trying to build the 64bit version.

but actually it finally worked. I didn’t had much time to test the dll, yet.

@ttrocha Windows 32bit only, using the mingw32 download from http://sourceforge.net/projects/mingw/files/

Unfortunately ran into the same problem using the mingw64, even though it contains the 32 bit binaries as well.

Actually tried the same approach as you, defining the MAKE_C_COMPILER and CMAKE_CXX_COMPILER, however just ran into problems further on.



I’ll be looking into this again today, as I’m using Windows as dev platform …and really it should be possible for this to work producing 32 & 64 bit binaries for Windows.

Actually so far I never succeded in building for windows with 64bit, mingw32 works fine however.

@EmpirePhenix mingw32 works like a treat 8)



However, had moderate success …can build bullet physics with both the 32 and 64 bit toolchains for mingw64!



Turns out the problem lies with CMake and the default variables. As suggested somewhere on the mingw64 site removed the prefix for every exe under the bin directory, put them onto the %PATH% and bullet made a built without error :slight_smile:



The Make for mingw64 does not come with the binary distribution but as a separate download, titled ‘Make’ containing both a 32bit and 64bit make …who’d guessed.



Now, the proper way to do the build would be using the CMake variables, however after trying that I gave up for the time being.



Another problem was the bullet physics wouldn’t build:





[cc] …buildbullet-baselibBulletCollision.a(btPolyhedralContactClipping.obj):btPolyhedralContactClipping.cpp:(.eh_frame+0x15b): undefined reference to ___gxx_personality_v0'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHull.obj):btConvexHull.cpp:(.text+0x24a1): undefined reference to __Unwind_Resume’

[cc] …buildbullet-baselibLinearMath.a(btConvexHull.obj):btConvexHull.cpp:(.text+0x289f): undefined reference to __Unwind_Resume'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHull.obj):btConvexHull.cpp:(.text+0x41dc): undefined reference to __Unwind_Resume’

[cc] …buildbullet-baselibLinearMath.a(btConvexHull.obj):btConvexHull.cpp:(.text+0x4651): undefined reference to __Unwind_Resume'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHull.obj):btConvexHull.cpp:(.text+0x60f7): undefined reference to __Unwind_Resume’

[cc] …buildbullet-baselibLinearMath.a(btConvexHull.obj):btConvexHull.cpp:(.eh_frame+0x4cf): undefined reference to ___gxx_personality_v0'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.text+0xed77): undefined reference to __Unwind_Resume’

[cc] …buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.text+0xfae0): undefined reference to __Unwind_Resume'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.text+0x10364): undefined reference to __Unwind_Resume’

[cc] …buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.text+0x103b0): undefined reference to __Unwind_Resume'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.text$_ZN20btConvexHullInternalD1Ev[btConvexHullInternal::~btConvexHullInternal()]+0x12<br /> 0): undefined reference to __Unwind_Resume’

[cc] …buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.eh_frame+0x81f): undefined reference to ___gxx_personality_v0'<br /> [cc] ..........buildbullet-baselibLinearMath.a(btConvexHullComputer.obj):btConvexHullComputer.cpp:(.eh_frame$_ZN20btConvexHullInternalD1Ev+0x13): undefined reference to ___gxx_personali

ty_v0

[cc] ’

[cc] collect2.exe: error: ld returned 1 exit status



BUILD FAILED

C:DataDevelopmentjme3nbprojectbuild-bullet-natives.xml:420: gcc failed with return code 1





Don’t know whether that was down to update of jme did before hand (will check with mingw32 sometime)



…Anyway just thought I’d share the good word!

1 Like

Happy days …solved the above problem.



Turns out the problem was at the linking phase (after the object file were created), caused by copies of the *.a files from another compiler that are copied into jme3/build/bullet-base directory…which means I’ve got the mingw64 32bit tool chain working!



Now started on the 64bit & succeeded in compiling bullet standalone, hopefully with an alteration to the ant script and it’ll work from the build-native-bullet.xml as well :slight_smile:



The final step after that will be configuring the mingw64 to work without renaming the executables (by dropping the prefix), as that’ll be needed to build both 64 bit & 32 bit targets on the same machine.

2 Likes
@monkey_scratches_head said:
Happy days ...solved the above problem.

Turns out the problem was at the linking phase (after the object file were created), caused by copies of the *.a files from another compiler that are copied into jme3/build/bullet-base directory...which means I've got the mingw64 32bit tool chain working!

Now started on the 64bit & succeeded in compiling bullet standalone, hopefully with an alteration to the ant script and it'll work from the build-native-bullet.xml as well :)

The final step after that will be configuring the mingw64 to work without renaming the executables (by dropping the prefix), as that'll be needed to build both 64 bit & 32 bit targets on the same machine.

Hey, thats awesome news, if you got anything to test on our build server (linux mingw cross-compile) just post it here and I will check it. If we get just this one target to work we got automatic binary compiles for all platforms, yay.
1 Like

Was there any advances with this?

Ah, hello!



Sorry for the lateness in reply however I’ve been away down in Melbourne and have only just returned to a computer!



The short answer is: no



The long answer is: got stuck, decided to work on some assets and artwork, had an something resembling a mid-life crisis, then came back to Brisbane.



Basically, was up to the point of trying to coax CMake to play nicely without using the environment variables, unfortunately configuration management is something I’ve very little patience for, so easily switch over to other things.



In the long term though, I’m exciting about getting the native bullet working with JME, as I’m certain that it’s a positive step forward and something I intend to use …basically I’ve got about 5 hours a week for game development, where I’ll now spend some time on trying to get this working, but realistically due to amount of time spare, progress may be slow.



I’ll update / bump this thread each week with progress, where the accountability will help me to actually get some traction on this!

1 Like

Cool, thanks

Okay, taken a little while to get back around to this, but as promised a quick update!



Basically got back up to speed and figured out how to get the permissive flag into the compiler so now the 64 bit is building - just need to install a 64 bit JRE to check it actually all works (getting the bulletjme.dll: Can’t load AMD 64-bit .dll on a IA 32-bit platform).

1 Like