I’m on Debian stable (Squeeze) and just tried to run native bulllet but it doesn’t work. Must be a rather recent change since I ran native bullet a few weeks ago. Will glibc 2.14 be needed from now on?
Exception in thread “main” java.lang.UnsatisfiedLinkError: /…/libbulletjme64.so: /lib/libc.so.6: version `GLIBC_2.14’ not found (required by …/libbulletjme64.so)
Uhm, honestly I am no expert on linux dependencies, what kernel does this come with normally and what does the current one come with? We use the normal bullet build process, maybe this has been advanced in a later version? We use 2.80.
Thanks, I’ll look around at bullet and see what I can find.
Debian is pretty conservative about upgrading, I think the next version of Debian stable will be glibc2.13. Latest release of Ubuntu is at glibc2.15 I think.
1 Like
@jmaasing said:
Thanks, I'll look around at bullet and see what I can find.
Debian is pretty conservative about upgrading, I think the next version of Debian stable will be glibc2.13. Latest release of Ubuntu is at glibc2.15 I think.
Oh wow okay, that way round, I see. Then its more probable some part of our build system is "too recent", eh? Gonna check if I can find out something.
I did a quick test, building bullet 2.81 on my machine (with glibc 2.11) and the build went fine.
Haven’t tested anything yet - need to figure out how to use the newly built libraries instead of the natives packaged with jME 
@jmaasing said:
I did a quick test, building bullet 2.81 on my machine (with glibc 2.11) and the build went fine.
Haven't tested anything yet - need to figure out how to use the newly built libraries instead of the natives packaged with jME :)
You need to build the jme binaries, bullet is built statically into them as the bullet manual suggests. You can build "our" bullet natives (and the jar containing them) with the bullet build target in our ant script, check the build-bullet-natives.txt in trunk/engine/
For sure, will do that after sleeping Since bullet built I don’t think that in itself has a requirement for glibc 2.14 - probably something that snuck in during the build process.
1 Like
@jmaasing said:
For sure, will do that after sleeping :) Since bullet built I don't think that in itself has a requirement for glibc 2.14 - probably something that snuck in during the build process.
Yeah sounds like it, lets see how I can do that in Linux w/o sacrificing a goat...
Just managed to build the natives and point them out in my project in the SDK, built with GNU C Library (Debian EGLIBC 2.11.3-3).
Only done limited testing, threw a rigidbody onto a terraingrid and watched it roll and tumble, always fun.
So bullet 2.80 does not require glibc2.14, must be the build machine having that version. Would make us Debian people happy if 2.14 wasn’t required whenever native bullet is “done”
1 Like
Alright, thanks!
Looked into this, I haven’t written a C/C++ since JDK1.0 was released and I suddenly recalled why that was so
http://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version
Options are, either:
- install a machine with “old” version of libraries.
- Create a cross-compiler x86->x86 with all the old libraries
Or some variation of this with chroot
So yeah, seems like the easiest way is to actually sacrifice a goat.
1 Like
/sigh