From ulo_kapta at hotmail.com Tue Aug 2 02:45:10 2011 From: ulo_kapta at hotmail.com (Kapta Ulo) Date: Tue, 2 Aug 2011 09:45:10 +0000 Subject: "libjawt.so" not loaded by Java 7 Message-ID: Hi, The Java 7 release seems to have broken the LWJGL project on Linux, it no longer works and complains that "libjawt.so" is not loaded. The project has been calling the following method: java.awt.Toolkit.getDefaultToolkit(); to ensure that this native file is loaded, this has worked fine for the last 6 or so years. There seems to have been some internal change which causes this to break. Any idea's on what it could be and how to fix this? There is some more information on the LWJGL forum here http://lwjgl.org/forum/index.php/topic,4085.0.html Some people have found a workaround using "sudo ldconfig /opt/java/jre/lib/amd64/" which they claim allows it to work as before, but doesn't really explain why its failing, any idea's or pointers would be appreciated. Thanks Kapta From David.Holmes at oracle.com Tue Aug 2 03:25:16 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 02 Aug 2011 20:25:16 +1000 Subject: "libjawt.so" not loaded by Java 7 In-Reply-To: References: Message-ID: <4E37D08C.2060509@oracle.com> Kapta Ulo said the following on 08/02/11 19:45: > The Java 7 release seems to have broken the LWJGL project on Linux, it no longer works and complains that "libjawt.so" is not loaded. The project has been calling the following method: java.awt.Toolkit.getDefaultToolkit(); to ensure that this native file is loaded, this has worked fine for the last 6 or so years. There seems to have been some internal change which causes this to break. Any idea's on what it could be and how to fix this? > There is some more information on the LWJGL forum here http://lwjgl.org/forum/index.php/topic,4085.0.html > Some people have found a workaround using "sudo ldconfig /opt/java/jre/lib/amd64/" which they claim allows it to work as before, but doesn't really explain why its failing, any idea's or pointers would be appreciated. I've cc'ed the AWT dev folk as they should know what has changed in 7. David > Thanks > Kapta From ahughes at redhat.com Tue Aug 2 22:37:37 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 3 Aug 2011 06:37:37 +0100 Subject: "libjawt.so" not loaded by Java 7 In-Reply-To: References: Message-ID: <20110803053737.GA31431@rivendell.middle-earth.co.uk> On 09:45 Tue 02 Aug , Kapta Ulo wrote: > > Hi, > The Java 7 release seems to have broken the LWJGL project on Linux, it no longer works and complains that "libjawt.so" is not loaded. The project has been calling the following method: java.awt.Toolkit.getDefaultToolkit(); to ensure that this native file is loaded, this has worked fine for the last 6 or so years. There seems to have been some internal change which causes this to break. Any idea's on what it could be and how to fix this? > There is some more information on the LWJGL forum here http://lwjgl.org/forum/index.php/topic,4085.0.html > Some people have found a workaround using "sudo ldconfig /opt/java/jre/lib/amd64/" which they claim allows it to work as before, but doesn't really explain why its failing, any idea's or pointers would be appreciated. If adding the library on the system library path is fixing it, it could be related to: 6367077: Purge LD_LIBRARY_PATH usage from the launcher http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e 'Previously the launcher modified the LD_LIBRARY_PATH appropriately for the desired data model path, regardless if data models matched or not. The launcher subsequently exec'ed the desired executable, in order to make the LD_LIBRARY_PATH path available for the runtime linker. This is no longer the case, the launcher dlopens the target libjvm.so. All other required libraries are loaded by the runtime linker, by virtue of the $ORIGIN paths baked into the shared libraries, by the build infrastructure at compile time.' Have you only seen this with LWJGL i.e. can other Java applications find libjawt.so? > Thanks > Kapta -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ulo_kapta at hotmail.com Sat Aug 6 06:55:10 2011 From: ulo_kapta at hotmail.com (Kapta Ulo) Date: Sat, 6 Aug 2011 13:55:10 +0000 Subject: "libjawt.so" not loaded by Java 7 In-Reply-To: <20110803053737.GA31431@rivendell.middle-earth.co.uk> References: , <20110803053737.GA31431@rivendell.middle-earth.co.uk> Message-ID: Thanks for clearing that up, much appreciated. It seems that LWJGL was relying on java.awt.Toolkit.getDefaultToolkit(); to load libjawt.so, which had worked fine but is no longer the behaviour with Java 7. The fix/solution to the problem was to just manually load libjawt.so using System.loadLibrary("jawt"); Thanks Kapta > Date: Wed, 3 Aug 2011 06:37:37 +0100 > From: ahughes at redhat.com > To: ulo_kapta at hotmail.com > CC: jdk7-dev at openjdk.java.net > Subject: Re: "libjawt.so" not loaded by Java 7 > > On 09:45 Tue 02 Aug , Kapta Ulo wrote: > > > > Hi, > > The Java 7 release seems to have broken the LWJGL project on Linux, it no longer works and complains that "libjawt.so" is not loaded. The project has been calling the following method: java.awt.Toolkit.getDefaultToolkit(); to ensure that this native file is loaded, this has worked fine for the last 6 or so years. There seems to have been some internal change which causes this to break. Any idea's on what it could be and how to fix this? > > There is some more information on the LWJGL forum here http://lwjgl.org/forum/index.php/topic,4085.0.html > > Some people have found a workaround using "sudo ldconfig /opt/java/jre/lib/amd64/" which they claim allows it to work as before, but doesn't really explain why its failing, any idea's or pointers would be appreciated. > > If adding the library on the system library path is fixing it, it could be related to: > > 6367077: Purge LD_LIBRARY_PATH usage from the launcher > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e > > 'Previously the launcher modified the LD_LIBRARY_PATH appropriately for the > desired data model path, regardless if data models matched or not. The > launcher subsequently exec'ed the desired executable, in order to make the > LD_LIBRARY_PATH path available for the runtime linker. This is no longer the > case, the launcher dlopens the target libjvm.so. All other required > libraries are loaded by the runtime linker, by virtue of the $ORIGIN paths > baked into the shared libraries, by the build infrastructure at compile time.' > > Have you only seen this with LWJGL i.e. can other Java applications find libjawt.so? > > > Thanks > > Kapta > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From erik.trimble at oracle.com Fri Aug 12 17:42:38 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 12 Aug 2011 17:42:38 -0700 Subject: Retiring Hotspot gatekeeper... Message-ID: <1313196158.1843.497.camel@ghostbox> After almost 4 years as the OpenJDK Hotspot gatekeeper (and over 7 years as the Hotspot gatekeeper), I'm stepping down. My place will be taken by Alejandro Murillo. Interim assistance will be given by John Coomes. Hotspot gatekeeping is quite complex, as the Hotspot Express model demands a large amount of coordination as to where it goes and how it is tested. I greatly appreciate everyone's forbearance on some of the glitches that have happened, and plead with folks to be nice to Alejandro for a couple of months, while he comes up to speed. It's certainly never been dull. Thanks for everything, folks. -- Erik Trimble Java Platform Group - Infrastructure Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (UTC-0800)