Java OpenGL on FC4

[John M. Gabriele]

What's preferred for use on FC4: jogl or lwjgl? Or
is there a third option -- maybe some way to do it
with Java-Gnome?

I can't find jogl or lwjgl with yum search.

I found some jogl rpms in Anthony Green's folder:
http://people.redhat.com/green/FC4/

but when I try to install them it tells me:

[root@localhost temp]# ls *.rpm
jogl-1.1b11-1fc.i386.rpm  jogl-javadoc-1.1b11-1fc.i386.rpm
[root@localhost temp]# rpm -ihv jogl-*
error: Failed dependencies:
        libjawt.so.6 is needed by jogl-1.1b11-1fc.i386

Looks like a libjawt was renamed, but these rpms don't
know about it.

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Thomas Fitzsimmons]

On Sun, 2005-08-14 at 14:58 -0700, John M. Gabriele wrote:
> What's preferred for use on FC4: jogl or lwjgl? Or
> is there a third option -- maybe some way to do it
> with Java-Gnome?
>
> I can't find jogl or lwjgl with yum search.
>
> I found some jogl rpms in Anthony Green's folder:
> http://people.redhat.com/green/FC4/
>
> but when I try to install them it tells me:
>
> [root@localhost temp]# ls *.rpm
> jogl-1.1b11-1fc.i386.rpm  jogl-javadoc-1.1b11-1fc.i386.rpm
> [root@localhost temp]# rpm -ihv jogl-*
> error: Failed dependencies:
>         libjawt.so.6 is needed by jogl-1.1b11-1fc.i386
>
> Looks like a libjawt was renamed, but these rpms don't
> know about it.

At least some of the jogl tests work on Fedora Core 4.  Try rebuilding
Anthony's jogl RPMs from the SRPM:

rpmbuild --rebuild <jogl SRPM>

This bug prevents the building of lwjgl:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747

I plan to fix it in GNU Classpath as soon as the JAWT merge is complete.

Tom
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs
>
> --
> fedora-devel-java-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

[John M. Gabriele]

--- Thomas Fitzsimmons  wrote:
> On Sun, 2005-08-14 at 14:58 -0700, John M. Gabriele wrote:
> > What's preferred for use on FC4: jogl or lwjgl? Or
> > is there a third option -- maybe some way to do it
> > with Java-Gnome?
> >
> > I can't find jogl or lwjgl with yum search.
> >
> > I found some jogl rpms in Anthony Green's folder:
> > http://people.redhat.com/green/FC4/
> >
> > but when I try to install them it tells me:
> >
> > [root@localhost temp]# ls *.rpm
> > jogl-1.1b11-1fc.i386.rpm  jogl-javadoc-1.1b11-1fc.i386.rpm
> > [root@localhost temp]# rpm -ihv jogl-*
> > error: Failed dependencies:
> >         libjawt.so.6 is needed by jogl-1.1b11-1fc.i386
> >
> > Looks like a libjawt was renamed, but these rpms don't
> > know about it.
>
> At least some of the jogl tests work on Fedora Core 4.  Try rebuilding
> Anthony's jogl RPMs from the SRPM:
>
> rpmbuild --rebuild <jogl SRPM>

I ran:
rpmbuild --rebuild jogl-1.1b11-1fc.src.rpm

and it created three rpms:

[root@localhost temp]# ls -l /usr/src/redhat/RPMS/i386/
total 7556
-rw-r--r--  1 root root 4649324 Aug 14 20:44 jogl-1.1b11-1fc.i386.rpm
-rw-r--r--  1 root root 1781057 Aug 14 20:45 jogl-debuginfo-1.1b11-1fc.i386.rpm
-rw-r--r--  1 root root 1266692 Aug 14 20:44 jogl-javadoc-1.1b11-1fc.i386.rpm

I then installed them:

[root@localhost temp]# rpm -ihv /usr/src/redhat/RPMS/i386/*.rpm
Preparing...                ########################################### [100%]
   1:jogl-javadoc           ########################################### [ 33%]
   2:jogl                   ########################################### [ 67%]
   3:jogl-debuginfo         ########################################### [100%]

[root@localhost temp]# rpm -qa | grep -i jogl
jogl-1.1b11-1fc
jogl-javadoc-1.1b11-1fc
jogl-debuginfo-1.1b11-1fc

The user guide landed here:
file:///usr/share/doc/jogl-1.1b11/userguide/index.html

And the javadocs here:
file:///usr/share/javadoc/jogl-1.1b11/index.html

I put my notes on it here:
http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOpenGL

---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[John M. Gabriele]

--- "John M. Gabriele"  wrote:
> --- Thomas Fitzsimmons  wrote:
> > On Sun, 2005-08-14 at 14:58 -0700, John M. Gabriele wrote:
> > > What's preferred for use on FC4: jogl or lwjgl? Or
> > > is there a third option -- maybe some way to do it
> > > with Java-Gnome?
> > >
> > > I can't find jogl or lwjgl with yum search.
> > >
> > > I found some jogl rpms in Anthony Green's folder:
> > > http://people.redhat.com/green/FC4/
> > >
> > > but when I try to install them it tells me:
> > >
> > > [root@localhost temp]# ls *.rpm
> > > jogl-1.1b11-1fc.i386.rpm  jogl-javadoc-1.1b11-1fc.i386.rpm
> > > [root@localhost temp]# rpm -ihv jogl-*
> > > error: Failed dependencies:
> > >         libjawt.so.6 is needed by jogl-1.1b11-1fc.i386
> > >
> > > Looks like a libjawt was renamed, but these rpms don't
> > > know about it.
> >
> > At least some of the jogl tests work on Fedora Core 4.  Try rebuilding
> > Anthony's jogl RPMs from the SRPM:
> >
> > rpmbuild --rebuild <jogl SRPM>
>
> I ran:
> rpmbuild --rebuild jogl-1.1b11-1fc.src.rpm
>
> and it created three rpms:
>
> [root@localhost temp]# ls -l /usr/src/redhat/RPMS/i386/
> total 7556
> -rw-r--r--  1 root root 4649324 Aug 14 20:44 jogl-1.1b11-1fc.i386.rpm
> -rw-r--r--  1 root root 1781057 Aug 14 20:45
> jogl-debuginfo-1.1b11-1fc.i386.rpm
> -rw-r--r--  1 root root 1266692 Aug 14 20:44 jogl-javadoc-1.1b11-1fc.i386.rpm
>
> I then installed them:
>
> [root@localhost temp]# rpm -ihv /usr/src/redhat/RPMS/i386/*.rpm
> Preparing...                ###########################################
> [100%]
>    1:jogl-javadoc           ########################################### [
> 33%]
>    2:jogl                   ########################################### [
> 67%]
>    3:jogl-debuginfo         ###########################################
> [100%]
>
> [root@localhost temp]# rpm -qa | grep -i jogl
> jogl-1.1b11-1fc
> jogl-javadoc-1.1b11-1fc
> jogl-debuginfo-1.1b11-1fc
>
> The user guide landed here:
> file:///usr/share/doc/jogl-1.1b11/userguide/index.html
>
> And the javadocs here:
> file:///usr/share/javadoc/jogl-1.1b11/index.html
>
> I put my notes on it here:
> http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOpenGL
>
> ---John

Darn. Compiling a small test program to bytecode goes ok:

gcj --classpath=/usr/share/java/jogl.jar -C Test.java

But when I try to run it, I get:

[john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar Test
Exception in thread "main" java.lang.UnsatisfiedLinkError: libjawt: file not
found
   at java.lang.Runtime._load(java.lang.String, boolean)
(/usr/lib/libgcj.so.6.0.0)
   at java.lang.Runtime.loadLibrary(java.lang.String)
(/usr/lib/libgcj.so.6.0.0)
   at java.lang.System.loadLibrary(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
   at net.java.games.jogl.impl.NativeLibLoader$1.run()
(/usr/lib/libjogl-1.1b11.jar.so)
   at
java.security.AccessController.doPrivileged(java.security.PrivilegedAction)
(/usr/lib/libgcj.so.6.0.0)
   at net.java.games.jogl.impl.NativeLibLoader.load()
(/usr/lib/libjogl-1.1b11.jar.so)
   at net.java.games.jogl.impl.x11.X11GLContextFactory.<clinit>()
(/usr/lib/libjogl-1.1b11.jar.so)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
   at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
(/usr/lib/libgcj.so.6.0.0)
   at java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
   at net.java.games.jogl.impl.GLContextFactory.getFactory()
(/usr/lib/libjogl-1.1b11.jar.so)
   at
net.java.games.jogl.GLDrawableFactory.createGLCanvas(net.java.games.jogl.GLCapabilities,
net.java.games.jogl.GLCapabilitiesChooser, net.java.games.jogl.GLDrawable,
java.awt.GraphicsDevice) (/usr/lib/libjogl-1.1b11.jar.so)
   at
net.java.games.jogl.GLDrawableFactory.createGLCanvas(net.java.games.jogl.GLCapabilities,
net.java.games.jogl.GLCapabilitiesChooser, net.java.games.jogl.GLDrawable)
(/usr/lib/libjogl-1.1b11.jar.so)
   at
net.java.games.jogl.GLDrawableFactory.createGLCanvas(net.java.games.jogl.GLCapabilities)
(/usr/lib/libjogl-1.1b11.jar.so)
   at Test.main(java.lang.String[]) (Unknown Source)
   at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)

Compiling to object works also:

gcj --classpath=/usr/share/java/jogl.jar -c Test.java

but trying to link that fails:

[john@localhost ~/dev/java/JOGL_Example]$ gcj
--classpath=/usr/share/java/jogl.jar --main=Test -o MyTest Test.o
Test.o(.text+0x1d): In function
`TestRenderer::init(net::java::games::jogl::GLDrawable*)':
Test.java: undefined reference to `net::java::games::jogl::GLDrawable::class$'
Test.o(.text+0x4b):Test.java: undefined reference to
`net::java::games::jogl::DebugGL::class$'
Test.o(.text+0x69):Test.java: undefined reference to
`net::java::games::jogl::GLDrawable::class$'
Test.o(.text+0x87):Test.java: undefined reference to
`net::java::games::jogl::DebugGL::DebugGL(net::java::games::jogl::GL*)'
Test.o(.text+0x9d):Test.java: undefined reference to
`net::java::games::jogl::GLDrawable::class$'
Test.o(.text+0x1ad): In function
`TestRenderer::display(net::java::games::jogl::GLDrawable*)':
Test.java: undefined reference to `net::java::games::jogl::GL::class$'
Test.o(.text+0x1df):Test.java: undefined reference to
`net::java::games::jogl::GL::class$'
Test.o(.text+0x20c):Test.java: undefined reference to
`net::java::games::jogl::GL::class$'
Test.o(.text+0x247):Test.java: undefined reference to
`net::java::games::jogl::GL::class$'
Test.o(.text+0x276):Test.java: undefined reference to
`net::java::games::jogl::GL::class$'
Test.o(.text+0x2b4):Test.java: more undefined references to
`net::java::games::jogl::GL::class$' follow
Test.o(.text+0x489): In function `Test::main(JArrayjava::lang::String**)':
Test.java: undefined reference to
`net::java::games::jogl::GLCapabilities::class$'
Test.o(.text+0x4a5):Test.java: undefined reference to
`net::java::games::jogl::GLCapabilities::GLCapabilities()'
Test.o(.text+0x5a2):Test.java: undefined reference to
`net::java::games::jogl::GLDrawableFactory::getFactory()'
Test.o(.text+0x646):Test.java: undefined reference to
`net::java::games::jogl::GLCanvas::addGLEventListener(net::java::games::jogl::GLEventListener*)'
Test.o(.text+0x651):Test.java: undefined reference to
`net::java::games::jogl::Animator::class$'
Test.o(.text+0x66b):Test.java: undefined reference to
`net::java::games::jogl::Animator::Animator(net::java::games::jogl::GLDrawable*)'
Test.o(.data+0x154): undefined reference to
`net::java::games::jogl::Animator::class$'
Test.o(.data+0x2c4): undefined reference to
`net::java::games::jogl::GL::class$'
Test.o(.data+0x2d4): undefined reference to
`net::java::games::jogl::GLDrawable::class$'
Test.o(.data+0x394): undefined reference to
`net::java::games::jogl::GLEventListener::class$'
collect2: ld returned 1 exit status

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Anthony Green]

On Sun, 2005-08-14 at 20:26 -0700, John M. Gabriele wrote:
> [john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar Test
> Exception in thread "main" java.lang.UnsatisfiedLinkError: libjawt: file not
> found
>    at java.lang.Runtime._load(java.lang.String, boolean)
> (/usr/lib/libgcj.so.6.0.0)

For some reason gij doesn't know where libjawt.so is.  I think fitzsim
and I have discussed, but I don't recall the result.

Try doing this before running your program.  It should fix it:

$ export LD_LIBRARY_PATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386
> Compiling to object works also:
>
> gcj --classpath=/usr/share/java/jogl.jar -c Test.java
>
> but trying to link that fails:
>
> [john@localhost ~/dev/java/JOGL_Example]$ gcj
> --classpath=/usr/share/java/jogl.jar --main=Test -o MyTest Test.o
> Test.o(.text+0x1d): In function
> `TestRenderer::init(net::java::games::jogl::GLDrawable*)':
> Test.java: undefined reference to `net::java::games::jogl::GLDrawable::class$'

There are two solutions:

1. Compile your code with -findirect-dispatch.

This will replace symbolic references to the jogl code with runtime name
lookups.

or

2. Link with -ljogl.jar.  This will link libjogl.jar.so to your program,
which should resolve all of the jogl symbols.

Good luck!

AG

[Thomas Fitzsimmons]

On Sun, 2005-08-14 at 22:21 -0700, Anthony Green wrote:
> On Sun, 2005-08-14 at 20:26 -0700, John M. Gabriele wrote:
> > [john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar Test
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: libjawt: file not
> > found
> >    at java.lang.Runtime._load(java.lang.String, boolean)
> > (/usr/lib/libgcj.so.6.0.0)
>
> For some reason gij doesn't know where libjawt.so is.  I think fitzsim
> and I have discussed, but I don't recall the result.
>
> Try doing this before running your program.  It should fix it:
>
> $ export LD_LIBRARY_PATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386

Yes, to fix this properly we need to add that directory to the
java.library.path system property.  I filed a bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23403

Tom
> > Compiling to object works also:
> >
> > gcj --classpath=/usr/share/java/jogl.jar -c Test.java
> >
> > but trying to link that fails:
> >
> > [john@localhost ~/dev/java/JOGL_Example]$ gcj
> > --classpath=/usr/share/java/jogl.jar --main=Test -o MyTest Test.o
> > Test.o(.text+0x1d): In function
> > `TestRenderer::init(net::java::games::jogl::GLDrawable*)':
> > Test.java: undefined reference to `net::java::games::jogl::GLDrawable::class$'
>
> There are two solutions:
> Compile your code with -findirect-dispatch.
>
> This will replace symbolic references to the jogl code with runtime name
> lookups.
>
> or
> Link with -ljogl.jar.  This will link libjogl.jar.so to your program,
>
> which should resolve all of the jogl symbols.
>
> Good luck!
>
> AG
>
> --
> fedora-devel-java-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

[John M. Gabriele]

--- Anthony Green  wrote:
> On Sun, 2005-08-14 at 20:26 -0700, John M. Gabriele wrote:
> > [john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar
>
> Test
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: libjawt: file
>
> not
> > found
> >    at java.lang.Runtime._load(java.lang.String, boolean)
> > (/usr/lib/libgcj.so.6.0.0)
>
> For some reason gij doesn't know where libjawt.so is.  I think fitzsim
> and I have discussed, but I don't recall the result.
>
> Try doing this before running your program.  It should fix it:
>
> $ export LD_LIBRARY_PATH=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386
> > Compiling to object works also:
> >
> > gcj --classpath=/usr/share/java/jogl.jar -c Test.java
> >
> > but trying to link that fails:
> >
> > [john@localhost ~/dev/java/JOGL_Example]$ gcj
> > --classpath=/usr/share/java/jogl.jar --main=Test -o MyTest Test.o
> > Test.o(.text+0x1d): In function
> > `TestRenderer::init(net::java::games::jogl::GLDrawable*)':
> > Test.java: undefined reference to
>
> `net::java::games::jogl::GLDrawable::class$'
>
> There are two solutions:
> Compile your code with -findirect-dispatch.
>
> This will replace symbolic references to the jogl code with runtime name
> lookups.
>
> or
> Link with -ljogl.jar.  This will link libjogl.jar.so to your program,
>
> which should resolve all of the jogl symbols.
>
> Good luck!
>
> AG

I think I'm gonna need just a bit more help.

So as not to confuse the issue, there's two different ways we're trying
to get this working here, and I'd like to get it working both ways:

1. using gcj to AOT compile then run directly, and

2. using gcj to compile to bytecode, then gij to run.

My code is just the simple code described here:
http://192.18.37.44/forums/index.php?topic=1474.0
(though I haven't yet gotten past the first few
messages on that thread)

The imports at the top look like:

import net.java.games.jogl.*;

import java.awt.*;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

------------------- compile to native, then run directly ---------------
I built with this:

gcj --classpath=/usr/share/java/jogl.jar \
 -c Test.java

(which gives me Test.o) then

gcj --classpath=/usr/share/java/jogl.jar \
 --main=Test -ljogl.jar -o MyTest Test.o

[john@localhost ~/dev/java/JOGL_Example]$ ls -l
total 68
-rwxrwxr-x  1 john john 25934 Aug 15 21:24 MyTest
-rw-rw-r--  1 john john  4873 Aug 15 21:07 Test.java
-rw-rw-r--  1 john john 16584 Aug 15 21:24 Test.o

[john@localhost ~/dev/java/JOGL_Example]$ ldd MyTest
        linux-gate.so.1 =>  (0x0066c000)
        libjogl.jar.so => /usr/lib/libjogl.jar.so (0x0066d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0056f000)
        libgcj.so.6 => /usr/lib/libgcj.so.6 (0x0259d000)
        libm.so.6 => /lib/libm.so.6 (0x003db000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00111000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00407000)
        libdl.so.2 => /lib/libdl.so.2 (0x00401000)
        libc.so.6 => /lib/libc.so.6 (0x002af000)
        /lib/ld-linux.so.2 (0x00291000)

[john@localhost ~/dev/java/JOGL_Example]$ echo $LD_LIBRARY_PATH
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386

[john@localhost ~/dev/java/JOGL_Example]$ ls -l
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386
total 4
lrwxrwxrwx  1 root root 23 Jul 30 01:25 libjawt.so -> /usr/lib/libgcjawt.so.6

[john@localhost ~/dev/java/JOGL_Example]$ ./MyTest
Exception in thread "main" java.lang.LinkageError: unexpected exception during
linking: net.java.games.jogl.GLCapabilities
   at java.lang.VMClassLoader.transformException(java.lang.Class,
java.lang.Throwable) (/usr/lib/libgcj.so.6.0.0)
   at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/usr/lib/libgcj.so.6.0.0)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
   at Test.main(java.lang.String[]) (Unknown Source)
   at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
Caused by: java.lang.NullPointerException
   at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/usr/lib/libgcj.so.6.0.0)
   ...4 more

----------------- compile to bytecode, then interpret -----------

Ok, I can build the bytecode like so:

gcj --classpath=/usr/share/java/jogl.jar -C Test.java

(just changing the above -c to -C)

then

[john@localhost ~/dev/java/JOGL_Example]$ echo $LD_LIBRARY_PATH
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386

and running it actually brings up a window and draws something
which is red and flickers a bit, but doesn't look like a triangle.
Here's the nasty-looking messages that come up in my terminal
window:

[john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar Test
Init GL is net.java.games.jogl.impl.x11.X11GLImpl

(.:3155): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in
cast to `GtkWidget'

(.:3155): GLib-GObject-WARNING **: invalid unclassed pointer in cast to
`GtkObject'

(.:3155): Gtk-CRITICAL **: gtk_widget_get_display: assertion `GTK_IS_WIDGET
(widget)' failed
Aborted

-------------------------

Thanks for any help,
---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[John M. Gabriele]

--- "John M. Gabriele"  wrote:
> --- Anthony Green  wrote:
> > On Sun, 2005-08-14 at 20:26 -0700, John M. Gabriele wrote:
> > >
> >
> > Good luck!
> >
> > AG
>
> I think I'm gonna need just a bit more help.
>
> So as not to confuse the issue, there's two different ways we're trying
> to get this working here, and I'd like to get it working both ways:
> 1. using gcj to AOT compile then run directly, and
>
> 2. using gcj to compile to bytecode, then gij to run.
>
>
> My code is just the simple code described here:
> http://192.18.37.44/forums/index.php?topic=1474.0
> (though I haven't yet gotten past the first few
> messages on that thread)

The code I'm trying to get running is here:

http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JOGLOnFC4

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Anthony Green]

On Mon, 2005-08-15 at 19:00 -0700, John M. Gabriele wrote:
> [john@localhost ~/dev/java/JOGL_Example]$ ./MyTest
> Exception in thread "main" java.lang.LinkageError: unexpected exception during
> linking: net.java.games.jogl.GLCapabilities

Rebuild your code with -findirect-dispatch and it will work.  I guess we
always need to use -findirect-dispatch, perhaps because we're
implementing an interface that was built using that option.
> [john@localhost ~/dev/java/JOGL_Example]$ echo $LD_LIBRARY_PATH
> /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386
>
> and running it actually brings up a window and draws something
> which is red and flickers a bit, but doesn't look like a triangle.

It's a triangle, although the flickering is really making it
unrecognizable.  If your test code used double buffering then all would
be good.

I don't know why the triangle is constantly being rerendered. Perhaps
this is normal behaviour.
> Here's the nasty-looking messages that come up in my terminal
> window:
>
> [john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar Test
> Init GL is net.java.games.jogl.impl.x11.X11GLImpl
>
> (.:3155): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in
> cast to `GtkWidget'
>
> (.:3155): GLib-GObject-WARNING **: invalid unclassed pointer in cast to
> `GtkObject'
>
> (.:3155): Gtk-CRITICAL **: gtk_widget_get_display: assertion `GTK_IS_WIDGET
> (widget)' failed
> Aborted

I don't get any of these messages.  Is your FC4 system up to date?

AG

[John M. Gabriele]

--- Anthony Green  wrote:
> On Mon, 2005-08-15 at 19:00 -0700, John M. Gabriele wrote:
> > [john@localhost ~/dev/java/JOGL_Example]$ ./MyTest
> > Exception in thread "main" java.lang.LinkageError: unexpected exception
>
> during
> > linking: net.java.games.jogl.GLCapabilities
>
> Rebuild your code with -findirect-dispatch and it will work.

Ok. Compiled from .java --> .o with that option and now it does
the same thing as when I run it via gij.

Which is weird, since the gcj man page has this to say:

| Note that, at present, "-findirect-dispatch" can only be used
| when compiling .class files.  It will not work when compiling
| from source.

Anyhow, at this point, I probably
need to look at the code itself to understand better why the
image is not looking right (and learn how to enable double-
buffering).

Trying to take a screenshot doesn't work b/c every time I hit
that PrintScn button, the flickering stops for an instant and
the screenshot only shows a blank black rendering window.
> I guess we
> always need to use -findirect-dispatch, perhaps because we're
> implementing an interface that was built using that option.
> > [john@localhost ~/dev/java/JOGL_Example]$ echo $LD_LIBRARY_PATH
> > /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386
> >
> > and running it actually brings up a window and draws something
> > which is red and flickers a bit, but doesn't look like a triangle.
>
> It's a triangle, although the flickering is really making it
> unrecognizable.  If your test code used double buffering then all would
> be good.

Yeah. I've gotta learn how to turn that on. :)
> I don't know why the triangle is constantly being rerendered. Perhaps
> this is normal behaviour.
> > Here's the nasty-looking messages that come up in my terminal
> > window:
> >
> > [john@localhost ~/dev/java/JOGL_Example]$ gij -cp /usr/share/java/jogl.jar
>
> Test
> > Init GL is net.java.games.jogl.impl.x11.X11GLImpl
> >
> > (.:3155): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)'
>
> in
> > cast to `GtkWidget'
> >
> > (.:3155): GLib-GObject-WARNING **: invalid unclassed pointer in cast to
> > `GtkObject'
> >
> > (.:3155): Gtk-CRITICAL **: gtk_widget_get_display: assertion `GTK_IS_WIDGET
> > (widget)' failed
> > Aborted
>
> I don't get any of these messages.  Is your FC4 system up to date?
>
> AG

Yup. Just did a "yum update". Note, I only get those messages (and
similar ones when running the natively compiled version) when closing
the window. Those messages aren't there when the window is up and
the red triangular shape is flickering.

http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JOGLOnFC4

I think I'm also gonna give sdljava a try also. I've tried
SDL in the past, and also like the idea of keeping everything
at least LGPL. ;)

Thanks,
---John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Robin Green]

On Tue, 16 Aug 2005 20:00:22 -0700, John M. Gabriele wrote:
> --- Anthony Green  wrote:
> > On Mon, 2005-08-15 at 19:00 -0700, John M. Gabriele wrote:
> > > [john@localhost ~/dev/java/JOGL_Example]$ ./MyTest
> > > Exception in thread "main" java.lang.LinkageError: unexpected exception
> >
> > during
> > > linking: net.java.games.jogl.GLCapabilities
> >
> > Rebuild your code with -findirect-dispatch and it will work.
>
> Ok. Compiled from .java --> .o with that option and now it does
> the same thing as when I run it via gij.
>
> Which is weird, since the gcj man page has this to say:
>
> | Note that, at present, "-findirect-dispatch" can only be used
> | when compiling .class files.  It will not work when compiling
> | from source.

Right. What I think Anthony *meant* was, follow the instructions on this
page: http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

[Anthony Green]

On Wed, 2005-08-17 at 16:57 +0100, Robin Green wrote:
> > > Rebuild your code with -findirect-dispatch and it will work.
> >
> > Ok. Compiled from .java --> .o with that option and now it does
> > the same thing as when I run it via gij.
> >
> > Which is weird, since the gcj man page has this to say:
> >
> > | Note that, at present, "-findirect-dispatch" can only be used
> > | when compiling .class files.  It will not work when compiling
> > | from source.
>
> Right. What I think Anthony *meant* was, follow the instructions on this
> page: http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

Hmm.. no, I really did mean compile your .java file with
-findirect-dispatch and it works.  Omit the -findirect-dispatch and the
program fails.

I don't know how to reconcile this with the advice in the gcj man page.

AG

[Tom Tromey]

> > > > > "Anthony" == Anthony Green  writes:

Anthony> Hmm.. no, I really did mean compile your .java file with
Anthony> -findirect-dispatch and it works.  Omit the
Anthony> -findirect-dispatch and the program fails.

-findirect-dispatch doesn't always work when you compile a .java file.
We ran out of time implementing this :-(.  We should have made this
case an error, but nobody thought of it before 4.0 shipped.

The currently supported approach is to compile to .class first.
At some point we will support compiling .java using -findirect-dispatch.

Tom

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Anthony Green  wrote:
> On Wed, 2005-08-17 at 16:57 +0100, Robin Green wrote:
> > > > Rebuild your code with -findirect-dispatch and it will work.
> > >
> > > Ok. Compiled from .java --> .o with that option and now it does
> > > the same thing as when I run it via gij.
> > >
> > > Which is weird, since the gcj man page has this to say:
> > >
> > > | Note that, at present, "-findirect-dispatch" can only be used
> > > | when compiling .class files.  It will not work when compiling
> > > | from source.
> >
> > Right. What I think Anthony *meant* was, follow the instructions on this
> > page: http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
>
> Hmm.. no, I really did mean compile your .java file with
> -findirect-dispatch and it works.  Omit the -findirect-dispatch and the
> program fails.
>
> [snip]

As long as that wiki page was mentioned, I wanted to interject
something about it: It's a good start, but I think it could use an
additional initial descriptive paragraph.

Excellent points to include might be:

1. What is the "new binary compatibility ABI" and why would it matter to
   me (J. Random Java Hacker)? Does it refer to linking with code that
   was natively compiled with an older (or newer?) version of GCJ?

2. Exactly why would I want to "treat GCJ as a kind of caching JIT"?
   Doesn't the libgcj runtime already do something like that?

3. The 3rd sentence says, "The original application remains unchanged".
   What is being discussed? What's the original application?

4. The 4th sentence says, "However, defineClass() is modified to find
   the executable form of the class in a shared library." Where's this
   defineClass() method defined? Why would it be in my code? Did I write
   it?

5. It goes on to talk about a ".db" file. Is a database involved here?

Anyhow, I'm certainly not complaining. It's great that someone has put
in the time to get that page up. I'm just providing some suggestions
on how it could be made more useful for the uninitiated.

IMO, free software projects live and die by the quality of their docs.

Thanks,
---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Bryce McKinlay]

John M. Gabriele wrote:
> What is the "new binary compatibility ABI" and why would it matter to
>
> me (J. Random Java Hacker)? Does it refer to linking with code that
>   was natively compiled with an older (or newer?) version of GCJ?
> Exactly why would I want to "treat GCJ as a kind of caching JIT"?
>
> Doesn't the libgcj runtime already do something like that?
> The 3rd sentence says, "The original application remains unchanged".
>
> What is being discussed? What's the original application?
> The 4th sentence says, "However, defineClass() is modified to find
>
> the executable form of the class in a shared library." Where's this
>   defineClass() method defined? Why would it be in my code? Did I write
>   it?
> It goes on to talk about a ".db" file. Is a database involved here?

John,

Some Java applications make assumptions about their runtime environment 
that made it very difficult to run them natively compiled without 
significant source code modifications. Specifically, these applications 
contain their own code to read bytecode streams and load them as classes 
using the ClassLoader.defineClass() method. The Eclipse IDE is a 
well-known example in which virtually the entire application is loaded 
in this manner.

The "kind of caching JIT" (aka: gcj-dbtool) model described here is 
GCJ's solution to this problem. When defineClass() is called, the 
bytecode passed is matched, using the map contained in the ".db" file, 
against shared libraries containing the classes compiled in advance to 
native code.

More typical applications that do not utilize custom classloaders do not 
need to worry about this at all. The BC-ABI (that is, the 
-findirect-dispatch option to gcj) can be used independently of 
gcj-dbtool to generate a binary that should continue to work despite 
changes to libgcj and other dependent class libraries. On the other 
hand, if you compile an application using the old style "C++ ABI", it 
will break as soon as any changes to the public APIs of dependent class 
libraries are made. In the past, as you can imagine, this was a 
significant limitation and an impediment to more widespread adoption of GCJ.

I agree with you that GCJs documentation could use a significant 
spruce-up, specifically in the area of entry-level, explanatory, and 
HOWTO type stuff. Let me assure you that any contributions to this 
effort will be gratefully received by the GCJ maintainers and quickly 
reviewed/applied.

Regards

Bryce

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Bryce McKinlay  wrote:

Thanks for the reply Bryce. I used much of it to update the
beginning of:
http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

It sounds like, to be able to mix interpreted and natively
compiled code at runtime, you need to have compiled your .jars
with the -findirect-dispatch option, right?

If so, why isn't -findirect-dispatch simply the default
compilation mode?
> [snip]
>
> On the other 
> hand, if you compile an application using the old style "C++ ABI", it 
> will break as soon as any changes to the public APIs of dependent class 
> libraries are made.

Right -- since the Java runtime should be smart enough to use
the lib as long as the signatures of the methods _it wants to
use_ match up, correct?

What does it mean to compile code with the "old style 'C++ ABI'"?
(Is that referred to as the "standard ABI"?) Does that just simply
mean to *not* use the -findirect-dispatch option?

Thanks,
---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Andrew Haley]

John M. Gabriele writes:
> --- Bryce McKinlay  wrote:
>
> Thanks for the reply Bryce. I used much of it to update the
> beginning of:
> http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
>
> It sounds like, to be able to mix interpreted and natively
> compiled code at runtime, you need to have compiled your .jars
> with the -findirect-dispatch option, right?
>
> If so, why isn't -findirect-dispatch simply the default
> compilation mode?

Its a bit slower, it's newer, and it doesn't work when compiling from
Java source.

I'm not sure when exactly -findirect-dispatch should become the
default, but not until compiling from source works.  That's not
particularly difficult to do, but it really requires some
rearrangement of the code in the compiler and we've been concentrating
on maximizing compatibility.

Longer term, I'd like to recover the performance losses with
-findirect-dispatch, and then we can make that the default with a
clear conscience.
> > On the other hand, if you compile an application using the old
> > style "C++ ABI", it will break as soon as any changes to the
> > public APIs of dependent class libraries are made.
>
> Right -- since the Java runtime should be smart enough to use
> the lib as long as the signatures of the methods _it wants to
> use_ match up, correct?
>
> What does it mean to compile code with the "old style 'C++ ABI'"?
> (Is that referred to as the "standard ABI"?) Does that just simply
> mean to *not* use the -findirect-dispatch option?

It does, yes.

Andrew.

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Bryce McKinlay]

John M. Gabriele wrote:
> Thanks for the reply Bryce. I used much of it to update the
> beginning of:
> http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

Great, thanks for doing this.
> It sounds like, to be able to mix interpreted and natively
> compiled code at runtime, you need to have compiled your .jars
> with the -findirect-dispatch option, right?

If you want to be able to call interpreted code from native code, yes. 
The other way around works fine regardless of the ABI.
> If so, why isn't -findirect-dispatch simply the default
> compilation mode?

Mostly because its not finished yet. The major blockers are CNI, because 
the C++ compiler does not yet understand the BC ABI, and the bug(s) 
affecting -findirect-dispatch when used for source code compilation. 
Certainly, the goal is to make BC the default ABI as soon as the issues 
are resolved.

There is also a performance hit from the BC-ABI - the tests I have done 
show this to be relatively small (<= 10%) for most applications, but it 
would be good to have more data.
> > [snip]
> >
> > On the other 
> > hand, if you compile an application using the old style "C++ ABI", it 
> > will break as soon as any changes to the public APIs of dependent class 
> > libraries are made.
>
> Right -- since the Java runtime should be smart enough to use
> the lib as long as the signatures of the methods _it wants to
> use_ match up, correct?

Right. The old ABI will break code in many situations, such as the order 
of fields or methods in a class changing. This is, obviously, 
unacceptable for Java.
> What does it mean to compile code with the "old style 'C++ ABI'"?
> (Is that referred to as the "standard ABI"?) Does that just simply
> mean to *not* use the -findirect-dispatch option?

Correct.

Bryce

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Tom Tromey]

> > If so, why isn't -findirect-dispatch simply the default
> > compilation mode?

Bryce> Mostly because its not finished yet. The major blockers are CNI,
Bryce> because the C++ compiler does not yet understand the BC ABI, and the
Bryce> bug(s) affecting -findirect-dispatch when used for source code
Bryce> compilation. Certainly, the goal is to make BC the default ABI as soon
Bryce> as the issues are resolved.

BTW there is a meta-pr that has dependencies on all the known BC ABI
tasks:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12725

(IMO not all of these are required to be fixed before we can flip the
default.)

Tom

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Bryce McKinlay  wrote:
> John M. Gabriele wrote:
> > Thanks for the reply Bryce. I used much of it to update the
> > beginning of:
> > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
>
> Great, thanks for doing this.

NP. :) I'm updating it as we go.
> > It sounds like, to be able to mix interpreted and natively
> > compiled code at runtime, you need to have compiled your .jars
> > with the -findirect-dispatch option, right?
>
> If you want to be able to call interpreted code from native code, yes.

So, we're talking about my natively compiled binary loading and
using some regular old .jar file full of .class files...

I don't get it. As I'm understanding it, if the natively compiled code
makes use of ClassLoader.defineClass(), it should just work right off the
bat without the native code having been built with -findirect-dispatch,
since when it tries to read a bytecode stream from the jar, it'll
find it there. No fuss, no muss, right?
> The other way around works fine regardless of the ABI.

[calling native code from interpreted code]

Suppose some interpreted Java program is running under gij on
my system, and needs to make use of one of some jar that it expects
to find on the CLASSPATH. Now, suppose I've secretly replaced this
program's regular coffee.jar with my natively compiled
coffee.jar.so.

Are you saying that it doesn't matter whether or not I've built my
coffee.jar.so with -findirect-dispatch? That libgcj will find it and
load it at runtime regardless?

That sounds backward to me: what if the interpreted
program makes a ClassLoader.defineClass() call? In that case,
it will be sorely disappointed when it hits my natively compiled
coffee.jar.so and there's no bytecode to be found. :)

Thanks,
---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Andrew Haley]

John M. Gabriele writes:
> --- Bryce McKinlay  wrote:
> > John M. Gabriele wrote:
> > > Thanks for the reply Bryce. I used much of it to update the
> > > beginning of:
> > > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
> >
> > Great, thanks for doing this.
>
> NP. :) I'm updating it as we go.
> > > It sounds like, to be able to mix interpreted and natively
> > > compiled code at runtime, you need to have compiled your .jars
> > > with the -findirect-dispatch option, right?
> >
> > If you want to be able to call interpreted code from native code, yes.
>
> So, we're talking about my natively compiled binary loading and
> using some regular old .jar file full of .class files...
>
> I don't get it. As I'm understanding it, if the natively compiled code
> makes use of ClassLoader.defineClass(), it should just work right off the
> bat without the native code having been built with -findirect-dispatch,
> since when it tries to read a bytecode stream from the jar, it'll
> find it there. No fuss, no muss, right?

Right, that's true.  And that will work.  However, if your compiled
program does something like

foo.bar();

where foo *only* exists in bytecode -- has never been gcj-compiled --
then that will *not* work.  But if your compiled program has been
compiled with -findirect-dispatch, then it will find the jar in the
classpath and load it.
> > The other way around works fine regardless of the ABI.
>
> [calling native code from interpreted code]
>
> Suppose some interpreted Java program is running under gij on
> my system, and needs to make use of one of some jar that it expects
> to find on the CLASSPATH. Now, suppose I've secretly replaced this
> program's regular coffee.jar with my natively compiled
> coffee.jar.so.

You can do that, but for full compatibility you're much better off
natively compiling coffee.jar.so and leaving coffee.jar where it
usually is.  If you add coffee.jar.so to the classmap database then,
when your application calls ClassLoader.defineClass(), gcj will load
from coffee.jar.so instead.
> Are you saying that it doesn't matter whether or not I've built my
> coffee.jar.so with -findirect-dispatch? That libgcj will find it and
> load it at runtime regardless?
>
> That sounds backward to me: what if the interpreted
> program makes a ClassLoader.defineClass() call? In that case,
> it will be sorely disappointed when it hits my natively compiled
> coffee.jar.so and there's no bytecode to be found. :)

Andrew.

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Andrew Haley  wrote:
> John M. Gabriele writes:
> > --- Bryce McKinlay  wrote:
> > > John M. Gabriele wrote:
> > > > Thanks for the reply Bryce. I used much of it to update the
> > > > beginning of:
> > > > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
> > >
> > > Great, thanks for doing this.
> >
> > NP. :) I'm updating it as we go.
> > > > It sounds like, to be able to mix interpreted and natively
> > > > compiled code at runtime, you need to have compiled your .jars
> > > > with the -findirect-dispatch option, right?
> > >
> > > If you want to be able to call interpreted code from native code, yes.
> >
> > So, we're talking about my natively compiled binary loading and
> > using some regular old .jar file full of .class files...
> >
> > I don't get it. As I'm understanding it, if the natively compiled code
> > makes use of ClassLoader.defineClass(), it should just work right off the
> > bat without the native code having been built with -findirect-dispatch,
> > since when it tries to read a bytecode stream from the jar, it'll
> > find it there. No fuss, no muss, right?
>
> Right, that's true.  And that will work.  However, if your compiled
> program does something like
>
> foo.bar();
>
> where foo *only* exists in bytecode -- has never been gcj-compiled --
> then that will *not* work.

*Only* exists in bytecode (if I'm understanding what you mean) is
just fine -- since that's what ClassLoader.defineClass() expects,
correct? My native code still knows how to deal with bytecode...

Hmm. Maybe I'm not understanding what you mean by only existing
in bytecode...

Is foo an instance of a class defined in the mystuff.jar file?
> But if your compiled program has been
> compiled with -findirect-dispatch, then it will find the jar in the
> classpath and load it.

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Andrew Haley]

John M. Gabriele writes:
> --- Andrew Haley  wrote:
> > John M. Gabriele writes:
> > > --- Bryce McKinlay  wrote:
> > > > John M. Gabriele wrote:
> > > > > Thanks for the reply Bryce. I used much of it to update the
> > > > > beginning of:
> > > > > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
> > > >
> > > > Great, thanks for doing this.
> > >
> > > NP. :) I'm updating it as we go.
> > > > > It sounds like, to be able to mix interpreted and natively
> > > > > compiled code at runtime, you need to have compiled your .jars
> > > > > with the -findirect-dispatch option, right?
> > > >
> > > > If you want to be able to call interpreted code from native code, yes.
> > >
> > > So, we're talking about my natively compiled binary loading and
> > > using some regular old .jar file full of .class files...
> > >
> > > I don't get it. As I'm understanding it, if the natively compiled code
> > > makes use of ClassLoader.defineClass(), it should just work right off the
> > > bat without the native code having been built with -findirect-dispatch,
> > > since when it tries to read a bytecode stream from the jar, it'll
> > > find it there. No fuss, no muss, right?
> >
> > Right, that's true.  And that will work.  However, if your compiled
> > program does something like
> >
> > foo.bar();
> >
> > where foo *only* exists in bytecode -- has never been gcj-compiled --
> > then that will *not* work.
>
> *Only* exists in bytecode (if I'm understanding what you mean) is
> just fine -- since that's what ClassLoader.defineClass() expects,
> correct? My native code still knows how to deal with bytecode...
>
> Hmm. Maybe I'm not understanding what you mean by only existing
> in bytecode...
>
> Is foo an instance of a class defined in the mystuff.jar file?

Yes.  Unless you are using indirect dispatch, the run-time dynamic
linker (i.e. that used by the OS for loading C programs) of your OS
will try to link against a shared object file and will fail if it
isn't there.  The gcj runtime doesn't even get consulted.

Andrew.

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Andrew Haley  wrote:
> John M. Gabriele writes:
> > --- Andrew Haley  wrote:
> > > John M. Gabriele writes:
> > > > --- Bryce McKinlay  wrote:
> > > > > John M. Gabriele wrote:
> > > > > > Thanks for the reply Bryce. I used much of it to update the
> > > > > > beginning of:
> > > > > > http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
> > > > >
> > > > > Great, thanks for doing this.
> > > >
> > > > NP. :) I'm updating it as we go.
> > > > > > It sounds like, to be able to mix interpreted and natively
> > > > > > compiled code at runtime, you need to have compiled your .jars
> > > > > > with the -findirect-dispatch option, right?
> > > > >
> > > > > If you want to be able to call interpreted code from native code,
>
> yes.
> > > > So, we're talking about my natively compiled binary loading and
> > > > using some regular old .jar file full of .class files...
> > > >
> > > > I don't get it. As I'm understanding it, if the natively compiled
>
> code
> > > > makes use of ClassLoader.defineClass(), it should just work right off
>
> the
> > > > bat without the native code having been built with
>
> -findirect-dispatch,
> > > > since when it tries to read a bytecode stream from the jar, it'll
> > > > find it there. No fuss, no muss, right?
> > >
> > > Right, that's true.  And that will work.  However, if your compiled
> > > program does something like
> > >
> > > foo.bar();
> > >
> > > where foo *only* exists in bytecode -- has never been gcj-compiled --
> > > then that will *not* work.
> >
> > *Only* exists in bytecode (if I'm understanding what you mean) is
> > just fine -- since that's what ClassLoader.defineClass() expects,
> > correct? My native code still knows how to deal with bytecode...
> >
> > Hmm. Maybe I'm not understanding what you mean by only existing
> > in bytecode...
> >
> > Is foo an instance of a class defined in the mystuff.jar file?
>
> Yes.  Unless you are using indirect dispatch, the run-time dynamic
> linker (i.e. that used by the OS for loading C programs) of your OS
> will try to link against a shared object file and will fail if it
> isn't there.  The gcj runtime doesn't even get consulted.
>
> Andrew.

Andrew -- I think there might be some confusion. I tried to keep
the two subjects as separated as possible, but perhaps I failed
(or I succeeded, and I'm just confused :). Further up in this post,
it reads:
> > > > So, we're talking about my natively compiled binary loading and
> > > > using some regular old .jar file full of .class files...

but your most recent reply seems to be discussing the case when
an interpreted Java program is using a natively compiled .jar.so...

I'm supposing
that the most common case is when you've got some program you want
natively compiled, and it relies on n-number of jars that you haven't
yet even tried to natively compile -- you just figure that your natively
compiled program will load them as necessary like before. In that case,
when building your app, you just specify your --classpath=... and let
gcj go off finding these jars that the app depends on.

Are you replying under another assumption -- namely, that the natively
compiled app was linked to mystuff.jar.so ( -lmystuff.jar ) at build-
time?

Thanks for all the help! :)

---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Andrew Haley]

John M. Gabriele writes:
> > Yes.  Unless you are using indirect dispatch, the run-time dynamic
> > linker (i.e. that used by the OS for loading C programs) of your OS
> > will try to link against a shared object file and will fail if it
> > isn't there.  The gcj runtime doesn't even get consulted.
>
> Andrew -- I think there might be some confusion. I tried to keep
> the two subjects as separated as possible, but perhaps I failed
> (or I succeeded, and I'm just confused :). Further up in this post,
> it reads:
> > > > > So, we're talking about my natively compiled binary loading and
> > > > > using some regular old .jar file full of .class files...
>
> but your most recent reply seems to be discussing the case when
> an interpreted Java program is using a natively compiled .jar.so...
>
> I'm supposing that the most common case is when you've got some
> program you want natively compiled, and it relies on n-number of
> jars that you haven't yet even tried to natively compile -- you
> just figure that your natively compiled program will load them as
> necessary like before.

gcj will only try to do that if you use indirect dispatch.
> In that case, when building your app, you just specify your
> --classpath=... and let gcj go off finding these jars that the app
> depends on.

If your app -- the one you're compiling to native code -- simply uses
some classes in a jar file and expects them to be loaded at runtime,
then your'e going to need indirect dispatch.

However, if your app calls ClassLoader.loadClass("C") to get a class C
and then invokes C.newInstance() then that will work.  What won't work
is if your natively compiled app does

new C();

See the difference?
> Are you replying under another assumption -- namely, that the natively
> compiled app was linked to mystuff.jar.so ( -lmystuff.jar ) at build-
> time?

No.

Andrew.

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Andrew Haley  wrote:
> John M. Gabriele writes:
> > [snip]
> >
> > I'm supposing that the most common case is when you've got some
> > program you want natively compiled, and it relies on n-number of
> > jars that you haven't yet even tried to natively compile -- you
> > just figure that your natively compiled program will load them as
> > necessary like before.
>
> gcj will only try to do that if you use indirect dispatch.

Thanks for your patience.

I thought the whole point of using -findirect-dispatch was when
you compile your mystuff.jar --to--> libmystuff.jar.so, and then,
right after that, to use gcj-dbtool on it so that any apps (natively
compiled or else interpreted) could find and use your
libmystuff.jar.so at runtime when the app asks libgcj for
mystuff.jar.

What we've been discussing, and what you're talking about here,
is when, at runtime, a natively compiled app wants to load/use
an actual jar file. What in blazes does it matter whether or not
my app was natively compiled with -findirect-dispatch? Nobody's
trying to use ClassLoader.defineClass() to load my app's classes.
> > In that case, when building your app, you just specify your
> > --classpath=... and let gcj go off finding these jars that
> > the app depends on.
>
> If your app -- the one you're compiling to native code -- simply uses
> some classes in a jar file and expects them to be loaded at runtime,
> then your'e going to need indirect dispatch.

Ok. You're saying that my natively compiled app -- which simply
has "import john.MyFooClass;" in it, and which also has
"MyFooClass za = new MyFooClass(); za.doStuff();" in it -- must be
compiled with -findirect-dispatch (and of course linked with
--classpath=/path/to/mystuff.jar) so it can load mystuff.jar at
runtime (where mystuff.jar contains MyFooClass.class in it). Of
course, when I run it, I'll still have to have the CLASSPATH
set to point to that mystuff.jar.

I'll try that as soon as I get home, after I get the dogs outside
for a bit, read the kids some stories about Java and Great GNU,
and put them to bed.
> However, if your app calls ClassLoader.loadClass("C") to get a class C
> and then invokes C.newInstance() then that will work. What won't work
> is if your natively compiled app does
>
> new C();
>
> See the difference?

Hmm.

Hmmmmmmm....

Ahhh.

It's sounding like, if I natively compile my app with
indirect dispatch, and link it with
--classpath=/path/to/mystuff.jar, and run it with
$CLASSPATH correctly pointing to that jar, then it buys
me some convenience. I can simply put in my imports,
and use the classes in mystuff.jar just like using
java.util.Date.

Without indirect dispatch, I've guess I've got to use
loadClass("MyFooClass"), then "MyFooClass.newInstance()"
(which I have to have implemented beforehand)... but
I don't see the difference between
"MyFooClass.newInstance()" and "new MyFooClass()".

Earlier, you mentioned:
> > [snip] Unless you are using indirect dispatch, the run-time
> > dynamic linker (i.e. that used by the OS for loading C programs)
> > of your OS will try to link against a shared object file and
> > will fail if it isn't there.  The gcj runtime doesn't even
> > get consulted.

I still don't know why you wrote that. When natively compiling
my Java app, I wouldn't be specifying any -lanything, but rather,
I'd be using --classpath=/path/to/mystuff.jar. If it compiles
and links without needing any extra .so's, why would ld.so
go looking for stuff that I never told it my app needed?

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Mark Wielaard]

Hi John,

On Thu, 2005-08-18 at 14:01 -0700, John M. Gabriele wrote:
> What we've been discussing, and what you're talking about here,
> is when, at runtime, a natively compiled app wants to load/use
> an actual jar file. What in blazes does it matter whether or not
> my app was natively compiled with -findirect-dispatch? Nobody's
> trying to use ClassLoader.defineClass() to load my app's classes.

Maybe it helps if you think about the non -findirect-dispatch case as
doing direct-dispatch. In the old abi the code would try to Directly
jump to the compiled code of the other class. In the new BC
(-findirect-dispatch) abi case it jumps to the code of the other class
Indirectly which means that (among other things) it first checks whether
or not there is a native version of the class to jump to or if there is
not it falls back on the interpreted version.

People will probably cry about the above explanation, the real technical
details can be found in ftp://gcc.gnu.org/pub/gcc/summit/2004/GCJ%20New%
20ABI.pdf (and are about making sure that certain kinds of binary
compatibility rules are followed by native code with the above as nice
side-effect)

What Andrew tried to explain is that in the old case you could still
call interpreted code "indirectly" if you didn't refer to the actual
class names in your natively compiled source code. You could compile
against interfaces, then load some jar dynamicly and call the
interpreted classes through the interface methods (assuming those
classes implemented them).

Note that the interpreted code was always using "indirect-dispatch"
meaning that interpreted code would automatically call either the byte
code or native version depending on what was availble.

One thing that is somewhat confusing is that .class files can both be
seen as defining the API you are compiling agains, actual (byte) code
that can be interpreted or as (byte code) source that can be compiled to
native code. When using the --classpath=/path/to/mystuff.jar switch to
gcj you are only using the jar as "header files" defining an api to
compile against. But in the old case the native code would assume that
those classes would be native at runtime.

Hope this helps and isn't more confusing.

Cheers,

Mark

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

Thanks Mark!
http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

--- Mark Wielaard  wrote:
> Hi John,
>
> [snip]
>
> Hope this helps and isn't more confusing.

:)

---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

BC ABI (was "Re: Re: Java OpenGL on FC4")

[Andrew Haley]

John M. Gabriele writes:
> --- Andrew Haley  wrote:
> > John M. Gabriele writes:
> > > [snip]
> > >
> > > I'm supposing that the most common case is when you've got some
> > > program you want natively compiled, and it relies on n-number of
> > > jars that you haven't yet even tried to natively compile -- you
> > > just figure that your natively compiled program will load them as
> > > necessary like before.
> >
> > gcj will only try to do that if you use indirect dispatch.
>
> Thanks for your patience.
>
> I thought the whole point of using -findirect-dispatch was when
> you compile your mystuff.jar --to--> libmystuff.jar.so, and then,
> right after that, to use gcj-dbtool on it so that any apps (natively
> compiled or else interpreted) could find and use your
> libmystuff.jar.so at runtime when the app asks libgcj for
> mystuff.jar.

That's not the whole point, but it is a convenient feature.
> What we've been discussing, and what you're talking about here,
> is when, at runtime, a natively compiled app wants to load/use
> an actual jar file. What in blazes does it matter whether or not
> my app was natively compiled with -findirect-dispatch? Nobody's
> trying to use ClassLoader.defineClass() to load my app's classes.

The key difference is this: with indirect dispatch, gcj uses its own
mechanism for symbol lookups, whereas without indirect dispatch gcj
must rely on the operating system's runtime loader.  That runtime
loader doesn't know how to load jars, but it does know how to load
shared libraries.
> It's sounding like, if I natively compile my app with indirect
> dispatch, and link it with --classpath=/path/to/mystuff.jar, and
> run it with $CLASSPATH correctly pointing to that jar, then it buys
> me some convenience. I can simply put in my imports, and use the
> classes in mystuff.jar just like using java.util.Date.
>
> Without indirect dispatch, I've guess I've got to use
> loadClass("MyFooClass"), then "MyFooClass.newInstance()"
> (which I have to have implemented beforehand)... but
> I don't see the difference between
> "MyFooClass.newInstance()" and "new MyFooClass()".

But they are different.
> Earlier, you mentioned:
> > > [snip] Unless you are using indirect dispatch, the run-time
> > > dynamic linker (i.e. that used by the OS for loading C programs)
> > > of your OS will try to link against a shared object file and
> > > will fail if it isn't there.  The gcj runtime doesn't even
> > > get consulted.
>
> I still don't know why you wrote that. When natively compiling
> my Java app, I wouldn't be specifying any -lanything,

Well, that's your call.  Using -lfoo is a perfectly reasonable thing
to do though, and it will work without indirect dispatch.
> but rather, I'd be using --classpath=/path/to/mystuff.jar. If it
> compiles and links without needing any extra .so's, why would ld.so
> go looking for stuff that I never told it my app needed?

It wouldn't.  But if you did use -lfoo, then that would work.

Andrew.

BC ABI (was "Re: Re: Java OpenGL on FC4")

[John M. Gabriele]

--- Andrew Haley  wrote:
> John M. Gabriele writes:
> > --- Andrew Haley  wrote:
> > > John M. Gabriele writes:
> > > > [snip]
> >
> > I thought the whole point of using -findirect-dispatch was when
> > you compile your mystuff.jar --to--> libmystuff.jar.so, and then,
> > right after that, to use gcj-dbtool on it so that any apps (natively
> > compiled or else interpreted) could find and use your
> > libmystuff.jar.so at runtime when the app asks libgcj for
> > mystuff.jar.
>
> That's not the whole point, but it is a convenient feature.

Yes! I see that now. Thanks!
> > What we've been discussing, and what you're talking about here,
> > is when, at runtime, a natively compiled app wants to load/use
> > an actual jar file. What in blazes does it matter whether or not
> > my app was natively compiled with -findirect-dispatch? Nobody's
> > trying to use ClassLoader.defineClass() to load my app's classes.
>
> The key difference is this: with indirect dispatch, gcj uses its own
> mechanism for symbol lookups, whereas without indirect dispatch gcj
> must rely on the operating system's runtime loader.  That runtime
> loader doesn't know how to load jars, but it does know how to load
> shared libraries.

Check.
> > It's sounding like, if I natively compile my app with indirect
> > dispatch, and link it with --classpath=/path/to/mystuff.jar, and
> > run it with $CLASSPATH correctly pointing to that jar, then it buys
> > me some convenience. I can simply put in my imports, and use the
> > classes in mystuff.jar just like using java.util.Date.
> >
> > Without indirect dispatch, I've guess I've got to use
> > loadClass("MyFooClass"), then "MyFooClass.newInstance()"
> > (which I have to have implemented beforehand)... but
> > I don't see the difference between
> > "MyFooClass.newInstance()" and "new MyFooClass()".
>
> But they are different.

Yes. I see. When you call the ctor, you're asking the runtime
to do its trick of automatically dynamically loading the class/jar.
> > Earlier, you mentioned:
> > > > [snip] Unless you are using indirect dispatch, the run-time
> > > > dynamic linker (i.e. that used by the OS for loading C programs)
> > > > of your OS will try to link against a shared object file and
> > > > will fail if it isn't there.  The gcj runtime doesn't even
> > > > get consulted.
> >
> > I still don't know why you wrote that. When natively compiling
> > my Java app, I wouldn't be specifying any -lanything,
>
> Well, that's your call.  Using -lfoo is a perfectly reasonable thing
> to do though, and it will work without indirect dispatch.

Right. I was still thinking of the case when your natively compiled
app needs to dynamically load all sorts of jars, and you don't want
to worry about natively compiling all of them. Check.
> > but rather, I'd be using --classpath=/path/to/mystuff.jar. If it
> > compiles and links without needing any extra .so's, why would ld.so
> > go looking for stuff that I never told it my app needed?
>
> It wouldn't.  But if you did use -lfoo, then that would work.
>
> Andrew.

Sweet. Thanks for the point-by-point reply Andrew. Much appreciated. :)

---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Andrew Haley]

Anthony Green writes:
> On Wed, 2005-08-17 at 16:57 +0100, Robin Green wrote:
> > > > Rebuild your code with -findirect-dispatch and it will work.
> > >
> > > Ok. Compiled from .java --> .o with that option and now it does
> > > the same thing as when I run it via gij.
> > >
> > > Which is weird, since the gcj man page has this to say:
> > >
> > > | Note that, at present, "-findirect-dispatch" can only be used
> > > | when compiling .class files.  It will not work when compiling
> > > | from source.
> >
> > Right. What I think Anthony *meant* was, follow the instructions on this
> > page: http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
>
> Hmm.. no, I really did mean compile your .java file with
> -findirect-dispatch and it works.  Omit the -findirect-dispatch and the
> program fails.

That's a bug which Tom Tromey fixed two days ago.
> I don't know how to reconcile this with the advice in the gcj man page.

Don't compile source with -findirect-dispatch.  This should be an
error in 4.1, and fixed soon after that.

Andrew.

[David Walluck]

Robin Green  wrote:
> Right. What I think Anthony *meant* was, follow the instructions on this
> page: http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

But we have aot-compile, so why not just use it instead and save some trouble?

By the way, I don't like how aot-compile combines the %build and 
%install steps.
This means that short-circuting to %install relly won't save you much time at
all (since aot-compile is called from there). Can't it run twice, once during
build where it creates the .so files, and once during %install where it
installs the created .so files to the correct path, or something like this?
Anyway, I think it would be better off as an rpm macro. I see some integration
happening as an RPM post script, which is nice too.

aot-compile combines %build and %install (was: Re: Re: Java OpenGL on FC4)

[Vadim Nasardinov]

On Wednesday 17 August 2005 22:49, David Walluck wrote:
> By the way, I don't like how aot-compile combines the %build and 
> %install steps.

Gary is best qualified to comment on this but if I am not mistaken, he is
on vacation right now.

[Tom Tromey]

> > > > > "David" == David Walluck  writes:
> > Right. What I think Anthony *meant* was, follow the instructions on this
> > page: http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ

David> But we have aot-compile, so why not just use it instead and
David> save some trouble?

aot-compile is a fedora-ism; that page is more about describing how
to use plain old gcj.  In Fedora packages it is definitely simpler to
just use aot-compile.

Tom

The thinking behind aot-compile-rpm (was: Java OpenGL on FC4)

[Gary Benson]

David Walluck wrote:
> By the way, I don't like how aot-compile combines the %build and 
> %install steps.

I'm guessing you're talking about aot-compile-rpm here...
> Can't it run twice, once during build where it creates the .so
> files, and once during %install where it installs the created .so
> files to the correct path, or something like this?

Not really.  The original reason for writing aot-compile-rpm was
that it was hard to maintain natively compiled packages with its
predecessors.  This was slowing Fedora's development in at least
two areas:

a) I maintain _a_lot_ of packages in Fedora that are independently
    maintained by the application server team.  Fedora constanly lags
    the appserver because the (many) appserver developers can pull in
    new versions far faster than I (one person) can port them to
    Fedora.  Now that these have been ported to Fedora's free Java
    environment it makes sense for at least some appserver development
    to occur on Fedora for greater community involvement, which of
    course requires that appserver maintainers must be able to
    maintain natively-compiled Fedora packages.

b) Now that libgcj is maturing many packages are gaining Java
    bindings (subversion, for example, and the databases) or whole
    chunks written in Java (OpenOffice).  I'd like their maintainers
    to be able to add and maintain native stuff without my continued
    intervention.

These two groups of maintainers have one thing in common: they don't
particularly care about gcj.  Ergo, aot-compile-rpm must be simple to
use, firstly so that non-gcj people use it at all, and secondly so
that it is used correctly.

Part of "correctly" means that every installed jarfile (and only every
installed jarfile!) has a solib.  This is non-trivial at the end of
%build because there are often jarfiles in the tree that are not
installed: testcases, for example, or build dependencies.  If native
compilation happens at the end of %build then you have to either:

- Compile the unwanted stuff anyway, wasting time compiling it,
   bandwidth transmitting it, and diskspace intalling it.  This was
   the major problem with find-and-aot-compile.

- List every jarfile you wanted to compile on the command line, or
   list every exclusion.  This places the burden of determining what's
   necessary on the maintainer, and risks missing useful stuff and
   compiling useless stuff.  This was the major problem with both
   aot-compile and katana.  Even if you get it right once, upgrades
   often break it silently.

There is another, less serious issue which arises from two-stage
compilation, in that jarfiles are often renamed during %install.
Both packaging and debugging are aided if the solibs have names
derived from the jarfiles they were built from.  To retain this
benefit a two-step aot-compile-rpm would require command-line options
or require the files to be manually renamed.  Katana had the former,
aot-compile used the latter, but both are unwieldy, basically
requiring the maintainer to state what was about to happen in
%install.  This is another thing that frequently breaks on upgrades.

Hope that explains things a little better.

Cheers,
Gary

[Anthony Green]

On Sun, 2005-08-14 at 14:58 -0700, John M. Gabriele wrote:
> What's preferred for use on FC4: jogl or lwjgl? Or
> is there a third option -- maybe some way to do it
> with Java-Gnome?

The java bindings for SDL include OpenGL support and are known to work
with gcj.

A while ago I considered pushing my jogl RPMs into Fedora Extras, but
there's a little problem that bothers me.  Our libjawt isn't binary
compatible with the Sun/IBM/BEA version, so I can't create a single jogl
RPM that will work with every "java" alternative.  Maybe this shouldn't
concern me too much, but it does.

The problem is that Sun doesn't publish the contents of jawt.h in a form
we can use, so I'm fairly certain our data structures are different from
Suns (we just infer the contents of jawt.h by looking at open source
code that uses it).

Suggestions on how to address this problem welcome...

AG

[John M. Gabriele]

--- Anthony Green  wrote:
> On Sun, 2005-08-14 at 14:58 -0700, John M. Gabriele wrote:
> > What's preferred for use on FC4: jogl or lwjgl? Or
> > is there a third option -- maybe some way to do it
> > with Java-Gnome?
>
> The java bindings for SDL include OpenGL support and are known to work
> with gcj.

Thanks! I hadn't thought to look for the Java SDL bindings.

In the past I'd written small OpenGL programs using glut,
so I was hoping to find a straight Java wrapper around freeglut
(and the rest of GL and GLU too, of course). Is there a Java
wrapper just for that?

Looks like, with JOGL, I've got to use AWT. Here's a quick
mini-tutorial I found on Sun's forum:
http://192.18.37.44/forums/index.php?topic=1474.0

Am I supposed to get the sdljava source from here:
http://sourceforge.net/project/showfiles.php?group_id=124821
or can someone point me to some FC4 rpm's?

Thanks,
---John

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

[Thomas Fitzsimmons]

On Sun, 2005-08-14 at 15:19 -0700, Anthony Green wrote:
> On Sun, 2005-08-14 at 14:58 -0700, John M. Gabriele wrote:
> > What's preferred for use on FC4: jogl or lwjgl? Or
> > is there a third option -- maybe some way to do it
> > with Java-Gnome?
>
> The java bindings for SDL include OpenGL support and are known to work
> with gcj.
>
> A while ago I considered pushing my jogl RPMs into Fedora Extras, but
> there's a little problem that bothers me.  Our libjawt isn't binary
> compatible with the Sun/IBM/BEA version, so I can't create a single jogl
> RPM that will work with every "java" alternative.  Maybe this shouldn't
> concern me too much, but it does.
>
> The problem is that Sun doesn't publish the contents of jawt.h in a form
> we can use, so I'm fairly certain our data structures are different from
> Suns (we just infer the contents of jawt.h by looking at open source
> code that uses it).
>
> Suggestions on how to address this problem welcome...

Yes, does anyone know of a tool that can extract structs from shared
libraries?

Tom
> AG
>
> --
> fedora-devel-java-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

[Tom Tromey]

Tom> Yes, does anyone know of a tool that can extract structs from shared
Tom> libraries?

Write a little program, link it with the library, and use 'ptype' in
gdb.

Tom