Glibc 2.14 Issues

I have a centos 6 dev server and I was trying to use it for working on a jme3 project.

Both client side and server side would not run. I belive it has to do with glibc_2.14 not being supported. Centos 6 uses an older version.

Client Side:
[java]INFO: Running on jMonkeyEngine 3.0.10
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/netx-native-12586/ which might have disabled stack guard. The VM will try to fix the stack guard now.
It’s highly recommended that you fix the library with ‘execstack -c <libfile>’, or link it with ‘-z noexecstack’.

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007f82f693a80e, pid=14670, tid=140200036222720

JRE version: OpenJDK Runtime Environment (7.0_65-b17) (build 1.7.0_65-mockbuild_2014_07_16_06_06-b00)

Java VM: OpenJDK 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)

Problematic frame:

C [] _dl_map_object_from_fd+0x81e

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try “ulimit -c unlimited” before starting Java again

An error report file with more information is saved as:


If you would like to submit a bug report, please include

instructions on how to reproduce the bug and visit:


Server Side:

[java]Oct 03, 2014 7:28:06 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.0.10
Exception in thread “main” java.lang.UnsatisfiedLinkError: /mnt/projects/project_a/ /lib64/ version `GLIBC_2.14’ not found (required by /mnt/projects/project_a/
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(
at java.lang.ClassLoader.loadLibrary0(
at java.lang.ClassLoader.loadLibrary(
at java.lang.Runtime.load0(
at java.lang.System.load(
at com.jme3.system.Natives.extractNativeLib(
at com.jme3.system.Natives.extractNativeLibs(
at com.jme3.system.JmeDesktopSystem.initialize(
at com.jme3.system.JmeDesktopSystem.newContext(
at com.jme3.system.JmeSystem.newContext(

Any help would be great,

The first error message gives the solution in the first two lines.

The second error is due to the native bullet version being alpha, they are compiled against glibc in a way thats not ideal. You can use the jbullet version however, which is the default for jME 3.0

OK, for the native bullet I removed the native physics lib and now it works.

As for the first one, I installed prelink and ran the ‘fixes’ given. But the file is a temp file and it’s path changes everytime I run the client side so the ‘fix’ does not actaully do anything.


nah, the is extracted to the project or the home folder, guess its loaded from the tmp folder because of that “stack guard” thingy

Ah, OK I have applied the ‘fixes’ to it, it was in the home folder, and it did not work. Is there a way to bypass this issue. I do not want my users running into this problem.

Also, it only does this when I run as a web start…

I suggest not using WebStart at all, it seems the technology lies dormant as of now (same as applets).

This program was designed to be web start, I am very interested in a fix at this point.

Maybe try the Oracle JDK instead. I think they upped the security measures around java web start so much that running a native library basically will always lead to problems. Otherwise ask Oracle directly.

It is possible, however you either need to set the security settings lower, or
alternativly wich i suggest.

Use a simple launcher, like getdown wich basically does the same as webstart(aka a small progress bar while downloading) , but without webstart.

As for the stack, the newest jdks request stack protected libs, to prevent them from crashing if the native part crashes. I think there is a cmd line argument to skip this.