Centox 6.x install

burlingk · February 16, 2014, 6:40am

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.

thanks!

normen · February 16, 2014, 11:58am

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?

burlingk · February 17, 2014, 2:03am

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.

jmaasing · February 17, 2014, 6:10am

normen said: Afaik theres no reason for a system to not be compatible to glibc 2.14 though?

Debian stable is not at 2.14 so I guess many Debian based systems also will have problems.

normen · February 17, 2014, 8:34am

Its funny this comes up now because the version of the sfxzip never changed since the installer contains the JDK…

Empire_Phoenix · February 17, 2014, 8:46am

@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.

https://www.archlinux.org/packages/core/x86_64/glibc/
glibc 2.19-2

Greetings to the yesterday distributions

burlingk · February 17, 2014, 8:47am

Depending on how the installer was created, that may not matter.

what likely matters most is which machine it was compiled on.

I am installing arch now. It tends to have bleeding edge options.

normen · February 17, 2014, 8:49am

@burlingk said: Depending on how the installer was created, that may not matter.
what likely matters most is which machine it was compiled on.

I am installing arch now. It tends to have bleeding edge options.

Yeah, what I am saying is that the same sfx executable is used, the one thats stored in our svn. So that dependency is clear.

burlingk · February 17, 2014, 9:19am

It is likely that I am just one of the first to try to use CentOS.

I should have known better than to try to do anything real with an “enterprise” distro.

tlf30 · June 8, 2014, 6:35pm

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.

Thanks,
Trevor

Arthur · January 28, 2015, 7:32am

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

Momoko_Fan · January 28, 2015, 3:03pm

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).

saxer81 · February 3, 2015, 8:08pm

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!

normen · February 3, 2015, 8:10pm

Actually its the unzipsfx version that doesn’t work on your old linux. You could use a platform independent zip however, see the simple .zip file here: http://updates.jmonkeyengine.org/stable/3.0/sdk/dist/

saxer81 · February 3, 2015, 8:15pm

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.