Glibc 2.14 Issues

Troubleshooting SDK
1

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/liblwjgl64.so 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 [ld-linux-x86-64.so.2+0x780e] _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:

/tmp/jvm-14670/hs_error.log

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

instructions on how to reproduce the bug and visit:

http://icedtea.classpath.org/bugzilla

#[/java]

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/libbulletjme64.so: /lib64/libc.so.6: version `GLIBC_2.14’ not found (required by /mnt/projects/project_a/libbulletjme64.so)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1851)
at java.lang.Runtime.load0(Runtime.java:795)
at java.lang.System.load(System.java:1062)
at com.jme3.system.Natives.extractNativeLib(Natives.java:200)
at com.jme3.system.Natives.extractNativeLibs(Natives.java:297)
at com.jme3.system.JmeDesktopSystem.initialize(JmeDesktopSystem.java:312)
at com.jme3.system.JmeDesktopSystem.newContext(JmeDesktopSystem.java:231)
at com.jme3.system.JmeSystem.newContext(JmeSystem.java:138)
at com.jme3.app.Application.start(Application.java:385)
at com.jme3.app.Application.start(Application.java:366)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:131)
[/java]

Any help would be great,
Thanks,
Trevor

2

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

3

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.

Thanks,
Trevor

4

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

5

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…

6

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

7

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

8

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.

9

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.