[FIXED] OpenAL Linux64 is not compiled (LWJGL 2.8)

[mifth]

Hi, OpenAL linux64bit does not compile. Just Want to say that.

Here is marked as red: https://www.newdawnsoftware.com/jenkins/

If the devs know about that issue, so just sorry.

[kappa]

This is compiling now, however since the solaris builds are still broken not sure the fixed openal linux 64bit natives have made it into the lwjgl nightly builds.

[mifth]

This is compiling now, however since the solaris builds are still broken not sure the fixed openal linux 64bit natives have made it into the lwjgl nightly builds.

That's cool!! Thank you!
Should I make this topic as (SOLVED)? I'm newbie here.

[kappa]

That's cool!! Thank you!
Should I make this topic as (SOLVED)? I'm newbie here.

Yeh sure, you can mark it as FIXED if you like. Usually best to wait a bit for a confirmed report or two that its actually fixed, in this case its only partially fixed (due to solaris builds still being broken and that it's still unclear if the fixed linux natives are actually part of lwjgl nightly builds due to this thread). Its something that'll need to be double checked before the LWJGL 2.8 release.

[mifth]

Yeh sure, you can mark it as FIXED if you like. Usually best to wait a bit for a confirmed report or two that its actually fixed, in this case its only partially fixed (due to solaris builds still being broken and that it's still unclear if the fixed linux natives are actually part of lwjgl nightly builds due to this thread). Its something that'll need to be double checked before the LWJGL 2.8 release.

Ok, I will wait, Thank you.

[phr00t]

I'm the lucky guy spamming that jMonkeyEngine forum with this error  

java.lang.UnsatisfiedLinkError: org.lwjgl.openal.AL10.initNativeStubs()V
	at org.lwjgl.openal.AL10.initNativeStubs(Native Method)
	at org.lwjgl.openal.AL.init(AL.java:156)
	at org.lwjgl.openal.AL.create(AL.java:138)
	at org.lwjgl.openal.AL.create(AL.java:102)
	at org.lwjgl.openal.AL.create(AL.java:201)
	at com.jme3.audio.lwjgl.LwjglAudioRenderer.initInThread(LwjglAudioRenderer.java:160)
	at com.jme3.audio.lwjgl.LwjglAudioRenderer.run(LwjglAudioRenderer.java:120)
[catch] at java.lang.Thread.run(Thread.java:662)

... is what I get. I am using the latest SVN today of jMonkeyEngine (which via r8272 updated to the latest nightly build of LWJGL for Sept. 22nd). I am running Ubuntu 11.04, 64-bit. Replacing LWJGL with the stable 2.7.1 branch gets rid of this exception. I have to disable the audio renderer (OpenAL) to run my jME3 applications on 2.8.0.

Thank you guys for looking into it...

(so no, unfortunately I do not think this bug is fixed yet...  )

[mifth]

I have the same issue with jMonkey and nightly builds.

Machine: kubuntu 11.04, 64bit.

[kappa]

The reason for the breakage is that the OpenAL-Soft people made some changes that makes it not compile on Solaris, I think they're aware of the issue, so as soon as they fix it the nightly builds should fix automatically on next build.

[Sworddragon]

The bug still exists in LWJGL #1352. LWJGL 2.8.0 is the first working version with the OpenJDK 7 on 64 Bit (as I said in the other thread LWJGL 2.7.1 and before have an architecture problem but OpenJDK 6 is working with it). So let's hope this bug get fixed fast.

[Endolf]

As of about an hour ago openal is finally building correctly on the farm again. Does lwjgl grab the latest successful build from that farm, or does someone need to do something to update the version lwjgl is using?.

Endolf

[Matzon]

I need to commit them - will do so tonight.

[kappa]

OpenAL with the latest nightly build of LWJGL on Linux 64bit still seems to be broken, don't think the latest fixes worked.

Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: org.lwjgl.openal.AL10.initNativeStubs()V
   at org.lwjgl.openal.AL10.initNativeStubs(Native Method)
   at org.lwjgl.openal.AL.init(AL.java:156)
   at org.lwjgl.openal.AL.create(AL.java:138)
   at org.lwjgl.openal.AL.create(AL.java:102)
   at org.lwjgl.openal.AL.create(AL.java:201)

Odd thing is I downloaded the last stable LWJGL 2.7.1 and replaced libopenal.so and libopenal64.so in the latest nightly builds and I still get the above error, could it be that some change in LWJGL is breaking the above? as opposed to OpenAL.

[kappa]

running with -Dorg.lwjgl.util.Debug=true gives the following output

[LWJGL] Xrandr extension version 1.3
[LWJGL] Using Xrandr for display mode switching
[LWJGL] XF86VidMode extension version 2.2
[LWJGL] Initial mode: 1680 x 1050 x 24 @50Hz
[LWJGL] Pixel format info: r = 8, g = 8, b = 8, a = 0, depth = 24, stencil = 0, sample buffers = 0, samples = 0
[LWJGL] MemoryUtil Accessor: AccessorUnsafe
Could not locate symbol glVertexWeighthNV
[LWJGL] getPathFromClassLoader: searching for: openal
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
[LWJGL] getPathFromClassLoader: searching for: lwjgl
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
[LWJGL] getPathFromClassLoader: searching for: lwjgl
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
[LWJGL] getPathFromClassLoader: searching for: lwjgl
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: sun.misc.Launcher$AppClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.net.URLClassLoader.findLibrary(java.lang.String)
[LWJGL] Failed to locate findLibrary method: java.lang.NoSuchMethodException: java.security.SecureClassLoader.findLibrary(java.lang.String)
[LWJGL] Found 9 OpenAL paths
[LWJGL] Testing '/home/computer/Desktop/lwjgl-2.8.0/native/linux/libopenal64.so'
[LWJGL] Found OpenAL at '/home/computer/Desktop/lwjgl-2.8.0/native/linux/libopenal64.so'
Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: org.lwjgl.openal.AL10.initNativeStubs()V
   at org.lwjgl.openal.AL10.initNativeStubs(Native Method)
   at org.lwjgl.openal.AL.init(AL.java:156)
   at org.lwjgl.openal.AL.create(AL.java:138)
   at org.lwjgl.openal.AL.create(AL.java:102)
   at org.lwjgl.openal.AL.create(AL.java:201)
   at org.bossattack.boing.SoundManager.initialize(SoundManager.java:118)
[LWJGL] XF86VidMode extension version 2.2

[kappa]

issue only seems to effect linux 64bit, works fine on linux 32bit.

The relevent native code seems to be inside
LWJGL > src > native > common > org_lwjgl_openal_ALC10.c

The code in there is some serious voodoo magic, not even gonna attempt to mess with it

SVN shows that only two changes were made to this file after the 2.7.1 release (one 2 months ago, another 6 weeks ago). Seems about the time the issue was reported, so might be a possible cause. Could any of those changes be relevant to such an issue?

[Matzon]

IMO, these changes are irrelevant.
I think the problem is somewhere in extal_InitializeClass, which is failing to find one or more method entries. However, I can't debug it since I don't have 64 bit readily available.