Forums › English Language Forums › Technical › Technical Issues

Search

[solved] Game not starting with (archlinux) jre 7?

22 replies [Last post]
Sun, 07/31/2011 - 05:21
Ufana

Hi!

SK stopped working after I updated JRE to version 7. Using jre 7-2 on archlinux x86_64... before I start looking into this: Any hints? Can someone confirm that SK is running with jre7 (or isn't)? Or did someone have similar problems and already found a solution?

thx...

edit:
Installing the game & running java in verbose mode, In get a "the configuration file is missing the application class". This might be unrelated though - never tried the downloadable version before & didn't try any further yet.

edit2:
after downgrading to jre 6u26, SK works again. Didn't find a solution and I'm not planning on keeping the obsolete jre version forever, so some help would be great.

Sun, 07/31/2011 - 07:12
#1
Starlinvf's picture
Starlinvf
Downloading the JREs for

Downloading the JREs for Windows to do some quick compatibility testing.

Sun, 07/31/2011 - 07:24
#2
Starlinvf's picture
Starlinvf
Game launches correctly in

Game launches correctly in Windows for both 32-bit and 64-bit Runtimes.

@"the configuration file is missing the application class" Are you sure all the launcher script is putting you in the right PWD or have a path to the SK directory? Check the launcher.log and see where the error is occuring.

Sun, 07/31/2011 - 08:18
#3
Ufana
"the configuration file is

"the configuration file is missing the application class" Are you sure all the launcher script is putting you in the right PWD or have a path to the SK directory?
Not sure at all, I have no Idea what I'm doing. I never used the install/bin before, I was using the web starter + never worked with java, so this message might just be a by-product of me miserably failing to run it verbosely.

Check the launcher.log and see where the error is occuring.
Did that: Not running with the verbose flag, there's nothing in it that looks useful (also the launcher just quits without any message). Running with the verbose flag, I get the same error as stated above(and the launcher freezez instead of just disappearing), just a little bit more detailed:

2011/07/31 16:50:11:312 WARNING e.a: Failed to parse 'getdown.txt': java.io.IOException: m.missing_class
-d32]
2011/07/31 16:50:12:474 WARNING e.a: getdown() failed.
java.io.IOException: m.missing_class
at com.threerings.getdown.data.Application.init(Unknown Source)
at com.threerings.getdown.launcher.Getdown.getdown(Unknown Source)
at com.threerings.getdown.launcher.Getdown.run(Unknown Source)

Everything else looks ok. Full log with verbose flag:
http://pastebin.com/bZPzJuQ5

Full log without my messing around / trying to make it tell me whats wrong:
http://pastebin.com/JT8DxBMS

Sun, 07/31/2011 - 08:41
#4
Starlinvf's picture
Starlinvf
The second run seems to have

The second run seems to have made it up to trying to launch the 2nd JVM for the game... but the dropping status in the last 2 lines are out of order from what I normally see in logs, but that may be nothing.

It should be generating a projectx.log file, see if it managed to create it. You can also try; ps -fe | grep java ; to see if any of the processes might be hung.

Sun, 07/31/2011 - 10:15
#5
Ufana
Ah, there that logfile was

Ah, there that logfile was hiding, thx!
Just gave it a quick try...

logfile says:
/liblwjgl.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
... so I hardlinked the 64 bit libraries in the SK ./native directory to the 32bit filenames:
$ for file in $(ls *64*); do newn=$(echo $file | sed "s/64//"); mv $newn bak && ln $file $newn; done;
As a Result I got the following error instead:
native/liblwjgl.so: libjawt.so cannot open shared object file: No such file or directory
"find / -iname libjawt* 2> /dev/null" says:
/opt/java/jre/lib/amd64/libjawt.so
After hardlinking that file to ~/spiral/native, I still get the same error. Maybe I just need to set an environment variable for that thing to download the right files or something...? well... enough random stuff for today, gonna take another look at that tomorrow... unless someone who actually knows what he's doing finds a solution until then...? :D

( Didn't get to read though all the changelogs and search the bugtrackers yet... so this might just be a packaging issue with my distro or something, I'll find out later ).

Sun, 07/31/2011 - 15:59
#6
xtremejoshua
Legacy Username
Just wanted to add to this

Just wanted to add to this thread that im using arch and have run into similar problems im not very experienced though so a bit lost as to a permanent solution if theres anything i can add to this thread to help just ask but again not experienced so youll have to tell me like a child xD im using x86 also not x86_64

Sun, 07/31/2011 - 22:52
#7
Starlinvf's picture
Starlinvf
https://bugs.archlinux.org/ta

https://bugs.archlinux.org/task/25305

So far its suspected to be a packaging problem with JRE7

Here is the suggested fix.

$ sudo ldconfig /opt/java/jre/lib/amd64/

************************
http://lwjgl.org/forum/index.php/topic,4085.0.html
http://getsatisfaction.com/mojang/topics/minecraft_doesnt_work_with_java_7
https://bbs.archlinux.org/viewtopic.php?id=123361

******
(Putting some previous steps for reference)
-Link the 64-bit libraries to the 32-bit names, then you have to muddle with it.
$ unset LD_LIBRARY_PATH
$ set LD_LIBRARY_PATH="/opt/java/jre/lib/amd64"
$ export LD_LIBRARY_PATH

This results in minecraft launching, but not functioning.

*******

Mon, 08/01/2011 - 01:05
#8
Ufana
Oh, thanks! That makes a lot

Oh, thanks! That makes a lot more sense then what I've been doing in the meantime... rolled back, took this solution, works fine now.

Mon, 08/01/2011 - 05:17
#9
Starlinvf's picture
Starlinvf
I tried to do some reading on

I tried to do some reading on ELF, dynamic linking and dependencies, and having some trouble wrapping my head around it.

http://www.iecc.com/linker/linker10.html
http://developers.sun.com/solaris/articles/elf.html
http://linux.about.com/od/commands/l/blcmdl8_ldconfi.htm
http://en.wikipedia.org/wiki/Dynamic_linker

Mon, 08/01/2011 - 07:44
#10
xtremejoshua
Legacy Username
Hi i just want to ask i found

Hi i just want to ask i found a solution by running

LD_LIBRARY_PATH="/opt/java/jre/lib/i386" ./spiral

I honestly dont know much about this even though im running arch linux and should be more knowledgeable is there a permanent fix for this?

from what you posted above ive tried
sudo ldconfig /opt/java/jre/lib/i386/

but that didnt work

Mon, 08/01/2011 - 19:34
#11
Starlinvf's picture
Starlinvf
The issue only seems to

The issue only seems to affect 64-bit JRE7. The directory should be amd64, not i386.

Tue, 08/02/2011 - 06:06
#12
xtremejoshua
Legacy Username
So then my problem is

So then my problem is unrelated? should i start a new thread?

EDIT: just adding i assumed that it was related as the problems only start when i updated my arch box with jre7

Tue, 08/02/2011 - 07:58
#13
Starlinvf's picture
Starlinvf
http://tldp.org/HOWTO/Program

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

the LD_LIBRARY_PATH environment variable is basically a "look here first" for libraries when an executable is looking something. It used mostly as debug or development trick to test shared objects that aren't properly registered with the OS.

Tue, 08/02/2011 - 08:36
#14
xtremejoshua
Legacy Username
Alright..confusing a little

Alright..confusing a little but i understand thank you

Wed, 08/03/2011 - 03:01
#15
Ufana
Did you try if downgrading

Did you try if downgrading gets rid of the problem?
Also: What do your log files say? I don't really trust java xD but unless it's running some really strange sort of VM I don't see how this could be a wrong ELF class on a 32bit system. I'm setting this "unsolved" for now until it's clear if your problem is related...

Wed, 08/03/2011 - 06:05
#16
xtremejoshua
Legacy Username
Well after updating to jre7 i

Well after updating to jre7 i was having problems launching the game...still very new to linux so didnt bother trying to troubleshoot i searched around and used a solution that people were using for minecraft link: https://bbs.archlinux.org/viewtopic.php?pid=967943 i would like to add i also had problems playing minecraft....i remember reading somewhere that there were alot of problems with the new java for both 64bit and 32 cant find the link anymore umm but i did read that downgrading to jre6 fixes most of these problems but had trouble doing that as well...

my projectx log i thing thats what your looking for right?

2011/08/03 08:58:48:994 INFO H$a.a: Logging to '/home/joshu/.getdown/spiral/./projectx.log'.
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/joshu/.getdown/spiral/native/liblwjgl.so: libjawt.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1928)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1854)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:82)
at org.lwjgl.Sys.(Sys.java:99)
at org.lwjgl.openal.AL.(AL.java:59)
at com.threerings.openal.q.(SourceFile:207)
at com.threerings.openal.q.a(SourceFile:73)
at com.threerings.opengl.e.(SourceFile:90)
at com.threerings.opengl.n.(SourceFile:55)
at com.threerings.projectx.client.ProjectXApp.(SourceFile:242)
at com.threerings.projectx.client.ProjectXApp.main(SourceFile:215)

EDIT: i see an error in there but no idea what it means...>.<

Wed, 08/03/2011 - 06:11
#17
xtremejoshua
Legacy Username
umm here is my launcher.log

umm here is my launcher.log if it helps any http://pastebin.com/LsbKvgEs

Wed, 08/03/2011 - 07:36
#18
Starlinvf's picture
Starlinvf
First make sure the file

First make sure the file exists.

Then: (Warning!! Educational)
http://linux.die.net/man/8/ldconfig
http://www.linux.com/archive/feature/114007
http://www.linux.com/component/content/article/130-distributions/417386

If I'm understanding it right, passing the directory as part of the ldconfig command tells it to scan and add it to the cache used to find linked libraries. /etc/ld.so.conf is used as fallback for items it can't figure out.

Wed, 08/03/2011 - 14:51
#19
xtremejoshua
Legacy Username
isnt there suppose to be alot

isnt there suppose to be alot of problems with java 7? both in arch linuxs packaging and upstream issues with both 32bit and 64? arnt there even warnings not to use it or report bugs and to wait for fixes

Thu, 08/04/2011 - 01:11
#20
Ufana
Mine works fine now - and as

Mine works fine now - and as you can see above, I had the same error as you after I tried to work around the 64-bit-issue.

Did you locate the library it can't find? Mine's there:

$ find /opt -iname libjawt.so 2> /dev/null
/opt/java/jre/lib/amd64/libjawt.so

I wouldn't recommend using /etc/ld.so.conf - looks like that file is being maintained in some package, guess user changes belong into new files in /etc/ld.so.conf.d/

Maybe just add the folder that file's in?

# dirname $(find /opt -iname libjawt.so 2> /dev/null) > /etc/ld.so.conf.d/jre7_workaround_delete_later.conf

edit: Also I guess it can't hurt to feed that path to that ldtoolthing, manual looks like its sort of useful:

# ldconfig $(dirname $(find /opt -iname libjawt.so 2> /dev/null))

Mmh... I'm not sure if I did it like that, It's already out of my bash history, so be careful...
Maybe you'd have better luck asking again in archlinux forum? Also I don't think it'll take long before that gets fixed by the maintainer, so if you want to play it safe: downgrade, wait. Old java should still be in your cache:

# pacman -U /var/cache/pacman/pkg/jre-6u26*pkg.tar.xz

Thu, 08/04/2011 - 02:38
#21
Starlinvf's picture
Starlinvf
You don't need to modify

You don't need to modify ld.so.config unless your doing something really odd. ldconfig builds a cache of links the system uses to find the libraries, and will automatically look in the /bin & /usr/bin, as well as whats in the ld.so.conf file and updates with any changes. Rather then modify anything, you can tell ldconfig what other directories it should look at via arguments.

It would also be safer to simply do a find, note the location, and enter it rather then chain a search command.

Fri, 08/05/2011 - 21:03
#22
xtremejoshua
Legacy Username
you can mark this as solved

you can mark this as solved now if you want...i dont have this problem with many games and its not the big a deal ill just wait for an update

Powered by Drupal, an open source content management system