jogl build problems

OpenGL Development JOGL Development
#1

Hi there,

I recently built jogl with gcj on Linux and was able to run a demo app. I hit a couple of problems along the way…

For the most part, the build process worked pretty well. The first problem was that I didn’t have a GLXFBConfig implementation. Is this supposed to be part of the cvs sources, or is it generated during the build process? I just wrote the following by hand in order to get things going:

                                                                      
package net.java.games.jogl.impl.x11;

import java.nio.ByteBuffer;

public class GLXFBConfig
{
    private ByteBuffer buffer;

    public GLXFBConfig (ByteBuffer b)
    {
        buffer = b;
    }

    public ByteBuffer getBuffer ()
    {
        return buffer;
    }
}

I was using a pre-release of GCC 4, and it complained about some errors (bad lvalues) in the generated C source. I’ll see if I can whip up a patch to fix the code generation.

If I do produce a patch, where do I send it? Do you have contribution guidelines, or require copyright assignment?

Thanks!

AG

#2

[quote]The first problem was that I didn’t have a GLXFBConfig implementation. Is this supposed to be part of the cvs sources, or is it generated during the build process?
[/quote]
It is generated during the build process when GlueGen is run over the X11 headers.

[quote]I was using a pre-release of GCC 4, and it complained about some errors (bad lvalues) in the generated C source. I’ll see if I can whip up a patch to fix the code generation.

If I do produce a patch, where do I send it? Do you have contribution guidelines, or require copyright assignment?
[/quote]
Please file an RFE (request for enhancement) using the Issue Tracker on http://jogl.dev.java.net . You will need to be an Observer of the project in order to modify your submitted bugs. I have seen similar warnings with various compilers but didn’t see anything obviously wrong with the generated C code, so it would be great if you could take a closer look.

There are contribution guidelines at https://games-core.dev.java.net/ but these typically only apply if you have Developer status and will be checking in your changes directly. Minor patches are typically checked in by the existing developer team and so far we haven’t added or modified the copyright notices in the code for patches of this size, although occasionally the comments contain the developer’s name or login for future reference.

#3

I finally figured out why gluegen wasn’t making GLXFBConfig.java for me. There’s a bug in gluegen’s CompoundType class. It is only operating correctly for most systems by chance.

CompoundType’s equals implementation breaks the basic contract requiring all equal objects to produce the same hashcode. If this contract is broken, then the class will not work properly in conjunction with all hash-based collections, including HashMap (which is used by gluegen).

This bug must be fixed in order to guarantee correct behaviour on all HashMap implementations (my implementation (from the gcj runtime library) triggers the bug).

I fixed this bug by simply adding the following to the start of CompoundType.equals…


if (hashCode() != arg.hashCode())
    return false;

Please fix this bug. Thanks!!

#4

We also need a little tweak in order to build with what will soon be released as GCC 4. Here’s a patch for both problems…

Index: src/net/java/games/gluegen/CMethodBindingEmitter.java
===================================================================
RCS file: /cvs/jogl/src/net/java/games/gluegen/CMethodBindingEmitter.java,v
retrieving revision 1.7
diff -u -r1.7 CMethodBindingEmitter.java
--- src/net/java/games/gluegen/CMethodBindingEmitter.java       4 Oct 2004 22:55:38 -0000       1.7
+++ src/net/java/games/gluegen/CMethodBindingEmitter.java       2 Apr 2005 09:02:11 -0000
@@ -609,7 +609,7 @@
             writer.print("  ");
             emitGetStringUTFChars(writer,
                                   "(jstring) _tmpObj",
-                                  "(const char*)"+convName+"_copy[_copyIndex]");
+                                  convName+"_copy[_copyIndex]");
           }
           else if (isNIOBufferClass(subArrayElementJavaType))
           {
Index: src/net/java/games/gluegen/cgram/types/CompoundType.java
===================================================================
RCS file: /cvs/jogl/src/net/java/games/gluegen/cgram/types/CompoundType.java,v
retrieving revision 1.2
diff -u -r1.2 CompoundType.java
--- src/net/java/games/gluegen/cgram/types/CompoundType.java    14 Jul 2003 05:34:51 -0000      1.2
+++ src/net/java/games/gluegen/cgram/types/CompoundType.java    2 Apr 2005 09:02:11 -0000
@@ -88,6 +88,8 @@
     if (arg == null || (!(arg instanceof CompoundType))) {
       return false;
     }
+    if (arg.hashCode() != hashCode())
+      return false;
     CompoundType t = (CompoundType) arg;
     return (super.equals(arg) &&
                        kind == t.kind &&
#5

Thanks for the patches, though I think they have a couple of problems. First, the removal of the (incorrect) cast to const char* in the CMethodBindingEmitter caused build warnings on other platforms. These were fixed by making the const declarations correct for the conversion case of String[] -> char**. Second, the addition of comparison of hashCodes in CompoundType.equals() seemed like too much of a hack. This was fixed by correcting potential problems in the equals() and hashCode() methods; I’m not sure whether this
will solve your original problem, though. I’d appreciate it if you could retest with the changes currently in the JOGL tree. See also your Issue 154, where I added the diffs checked in to the source tree.

#6

Thanks! I’ll try the latest CVS sources tomorrow.

When do expect the next JOGL release to be?

Thanks,

AG

#7

Probably in a week or two. We need to investigate some bugs that have been reported recently and apply some patches that have been filed.

#8

I just verified that the current cvs sources address both of my build problems. Thanks!