I am attempting to install the 64 bit version of the SDK on Centos 6.5.
I have the following results:
[burlingk@localhost Downloads]$ ./jmonkeyplatform-linux-x64.sh
Configuring the installer…
Searching for JVM on the system…
Preparing bundled JVM …
/tmp/.nbi-6023648.tmp/jdk-linux-x64.bin: /lib64/libc.so.6: version `GLIBC_2.14’ not found (required by /tmp/.nbi-6023648.tmp/jdk-linux-x64.bin)
Cannot extract bundled JVM
As you can see, it is trying to extract the JVM, and fails because the extraction program is linked against the wrong version of glibc.
It would make more sense for it to either use the JVM that is installed on the system already (it runs jme3 games just fine), or use the extraction program that is already installed on the system.
Anyway, does anyone know of a workaround for this? Which JVM is it trying to use, as that is likely a potential fix.
Its the sfx extraction of the JDK, the JDK is packed as a self-extracting ZIP so that it can unzip itself, it uses JDK 1.7u51. Did you download the installer just today? Because theres a new one up since yesterday. Afaik theres no reason for a system to not be compatible to glibc 2.14 though?
The reason the system is not compatible with glibc 2.14 is that glibc 2.12 is installed. Apparently Ubuntu (the newest ones at that) is the main distro actually compatible with 2.14 at the moment.
glibc is basically the foundation of any system in that it is a building block that every component on the system is compiled against so that it can interact with the operating system. Versions are generally backwards compatible, but there is no possible way to be forwards compatible, as you would be asking people to insure compatibility with things that do not exist.
I’ll give the new installer a try. If it doesn’t work, I will switch the Linux partition to Kubuntu (was hoping to avoid Ubuntu, but I would like to be able to work on dev issues in both Windows and Linux environments).
I may check to see which glibc version Arch is using.
@burlingk said:
So, it is using something built into itself.
The reason the system is not compatible with glibc 2.14 is that glibc 2.12 is installed. Apparently Ubuntu (the newest ones at that) is the main distro actually compatible with 2.14 at the moment.
glibc is basically the foundation of any system in that it is a building block that every component on the system is compiled against so that it can interact with the operating system. Versions are generally backwards compatible, but there is no possible way to be forwards compatible, as you would be asking people to insure compatibility with things that do not exist.
I’ll give the new installer a try. If it doesn’t work, I will switch the Linux partition to Kubuntu (was hoping to avoid Ubuntu, but I would like to be able to work on dev issues in both Windows and Linux environments).
I may check to see which glibc version Arch is using.
Hello,
I am having a similar issue when setting up a centos 6.5 workstation.
Configuring the installer...
Searching for JVM on the system...
Preparing bundled JVM ...
/tmp/.nbi-7063518.tmp/jdk-linux-x64.bin: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/.nbi-7063518.tmp/jdk-linux-x64.bin)
Cannot extract bundled JVM
I am using a 64 bit version. I was wondering if there was any fix for this. Netbeans 8.0 installs just fine.
Using Debian, have same problem with JME x64, some times the x86 stops on logo screen. Also have netbeans x64 installed on PC, and no problems with it.
Configuring the installer...
Searching for JVM on the system...
Preparing bundled JVM ...
/tmp/.nbi-3013406.tmp/jdk-linux-x64.bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/.nbi-3013406.tmp/jdk-linux-x64.bin)
Cannot extract bundled JVM
And got this errors when run application on x86 (just base game)
Exception in thread "LWJGL Renderer Thread" java.lang.UnsatisfiedLinkError: /home/arthur/BasicGame/liblwjgl.so: libXcursor.so.1: cannot open shared object file: No such file or directory
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 org.lwjgl.Sys$1.run(Sys.java:70)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:95)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:206)
at java.lang.Thread.run(Thread.java:744)
EDIT: On Debian go to Project properties / Libraries and Manage Platforms, add your existing jdk, then choose your added platform from list, then go to Application / Desktop and enable “Create Linux launcher” checkbox. This will fix x86 running issue on Debian, but x64 errors (installing JME) issue is still actual.
Thanks
It would be nice if using the bundled JDK could be skipped, but in any case jME3 SDK does require an updated system to run (its system requirements are higher than that of the engine).
I solved installing JDK issue on Debian Wheezy x64. The JDK bundled doesn’t run the installer due to glibc version. I have bypassed bundled JDK execution extracting the files inside jmonkey installer. You need a preinstalled JDK: I have JDK 1.7 from oracle.
Open a terminal and cd into directory that contains the installer:
cd where/is/jmonkey/installer/
extract the installer’s content:
./jmonkeyplatform-linux-x64.sh --extract
Now in that directory there are another 3 files:
TestJDK.class
jdk-linux-x64.bin (the JDK that causes the problem)
bundle.jar (JMonkey software that we want install)
All we have to do now is run this jar file to start the installer with JDK that we already have installed systemwide, run:
java -jar bundle.jar
on the terminal and installer starts, complete the installation as usual and enjoy jmonkey engine!
Thank you for your tip! I didn’t find this .zip version till now: maybe I was not so careful to locate it on the site! I’m new to the community and to JME3.