Please find attached a ebuild for java's OpenGL binding library.
Created attachment 93615 [details] jogl-1.0.0_beta5.ebuild
Created attachment 93741 [details] Updated ebuild Ive fixed up (hopefully) all of the things that were wrong in the previous ebuild.
I proposed a JOGL ebuild long ago (see bug 50178 and bug 71804). There were problems with the naming scheme used upstream. I support inclusion of JOGL in portage, perhaps the issue can be revisited? Since much of the discussion has already taken place there, I also suggest that this bug be marked as a duplicate of bug 50178 and we re-open bug 50178.
Whoops, ignore that last comment. I see that the problem has been addressed upstream! I should have looked more closely.
Created attachment 94194 [details] jogl-1.0.0_beta05.ebuild Another lot if fixes and tiding done.
This ebuild is now located in the migrated-java-experiemental-overlay. Specifically it is now located here http://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/jogl/
Please find attached an updated ebuild and associated patch for the final 1.0.0 release. Aside from the version bump it contains some additional dependencies and a patch for the JOGL native code compilation task. The patch changes the library search path from /usr/X11R6/lib{64} to /usr/lib{64}, and is required to build on my system.
Created attachment 104442 [details] jogl-1.0.0.ebuild Ebuild for 1.0.0 final release
Created attachment 104444 [details, diff] jogl-1.0.0-libpath.patch Patch to change link library search paths from /usr/X11R6/lib{64} to /usr/lib{64} when compiling native code.
Created attachment 106498 [details] new jogl-1.0.0.ebuild new jogl-1.0.0 contains the following tweeks, Increase memory for compiler. Add another patch
Created attachment 106500 [details, diff] jogl-1.0.0-fix-solaris-compiler.patch This patch fixes the build.xml that attempts to assign an incorrect compiler and linker ( suncc ) value.
This ebuild is available for review in the migrated-java-experimental overlay.
*** Bug 50178 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > *** Bug 50178 has been marked as a duplicate of this bug. *** > Alistair: Remember to check closed bugs too.
*** Bug 71804 has been marked as a duplicate of this bug. ***
jogl seems to bundle a copy of gluegen. I am not sure yet if it's worth it to use a system copy, but as joal uses it too it could be useful. https://gluegen.dev.java.net/
As both joal and jogl rely on gluegen, it really isn't acceptable for jogl to bundle it. Therefore I have made a gluegen ebuild and will attempt to hack jogl's build system to not bundle gluegen inside the jogl.jar
(In reply to comment #17) > As both joal and jogl rely on gluegen, it really isn't acceptable for jogl to > bundle it. Therefore I have made a gluegen ebuild and will attempt to hack > jogl's build system to not bundle gluegen inside the jogl.jar > Yes as long as we can it done in a way that it can be submitted to upstream like optionally with a property.
Currently my approach is to check whether the gluegen jars exist and base the decision to compile gluegen from this. So if we override the location of the gluegen jars using -Dgluegen.jar and -Dgluegen-rt.jar then gluegen will not be built. As for the bundling of gluegen in jogl. I'll tell you my approach after ive done it :)
(In reply to comment #12) > This ebuild is available for review in the migrated-java-experimental overlay. > # layman -i migrated-java-experimental * None Traceback (most recent call last): File "/usr/bin/layman", line 37, in ? main() File "/usr/bin/layman", line 34, in main Actions(Config()) File "/usr/lib/python2.4/site-packages/layman/action.py", line 473, in __init__ result += i[1](config).run() File "/usr/lib/python2.4/site-packages/layman/action.py", line 296, in run if not overlay.is_official(): AttributeError: 'NoneType' object has no attribute 'is_official'
hi, the discussion seems to have ceased here, am i right? the jogl ebuild attracts some more attention now as it is a dependency on scilab, as discussed over here http://bugs.gentoo.org/show_bug.cgi?id=237572 now, unfortunately, jogl seems to be the big blocker. any news on the gluegen dependency maybe? cheers, nico
I tried the ebuild from java-overlay on x86 and got the following error: ------------------------- [gluegen] WARNING: skipping emission of unnamed struct "struct __GLXFBConfigRec" [gluegen] WARNING: skipping emission of unnamed struct "struct __GLXFBConfigRec" [gluegen] WARNING: skipping emission of unnamed struct "struct __GLXFBConfigRec" [gluegen] WARNING: skipping emission of unnamed struct "struct { }" [gluegen] WARNING: skipping emission of unnamed struct "struct { }" [gluegen] WARNING: skipping emission of unnamed struct "struct { }" [gluegen] WARNING: Array fields (field "char[80] pipeName;" of type "GLXHyperpipeNetworkSGIX") not implemented yet [gluegen] WARNING: Array fields (field "char[80] pipeName;" of type "GLXHyperpipeNetworkSGIX") not implemented yet [gluegen] WARNING: skipping emission of unnamed struct "struct __GLXcontextRec" [gluegen] WARNING: skipping emission of unnamed struct "struct __GLXcontextRec" [gluegen] WARNING: skipping emission of unnamed struct "struct __GLXcontextRec" [gluegen] WARNING: Array fields (field "char[80] pipeName;" of type "GLXHyperpipeConfigSGIX") not implemented yet [gluegen] WARNING: Array fields (field "char[80] pipeName;" of type "GLXHyperpipeConfigSGIX") not implemented yet [gluegen] java.lang.RuntimeException: Error while generating bindings for "GLXFBConfig * glXChooseFBConfig(Display * dpy, int screen, const int * attribList, int * nitems);" [gluegen] at com.sun.gluegen.JavaEmitter.generateMethodBindingEmitters(JavaEmitter.java:630) [gluegen] at com.sun.gluegen.procaddress.ProcAddressEmitter.generateMethodBindingEmittersImpl(ProcAddressEmitter.java:117) [gluegen] at com.sun.gluegen.procaddress.ProcAddressEmitter.generateMethodBindingEmitters(ProcAddressEmitter.java:103) [gluegen] at com.sun.gluegen.JavaEmitter.emitFunctions(JavaEmitter.java:282) [gluegen] at com.sun.gluegen.GlueGen.run(GlueGen.java:283) [gluegen] at com.sun.gluegen.GlueGen.main(GlueGen.java:297) [gluegen] Caused by: java.lang.NullPointerException [gluegen] at com.sun.gluegen.JavaType.descriptor(JavaType.java:547) [gluegen] at com.sun.gluegen.JavaType.getDescriptor(JavaType.java:252) [gluegen] at com.sun.gluegen.MethodBinding.erasedTypeDescriptor(MethodBinding.java:590) [gluegen] at com.sun.gluegen.MethodBinding.getDescriptor(MethodBinding.java:569) [gluegen] at com.sun.gluegen.JavaConfiguration.javaPrologueForMethod(JavaConfiguration.java:664) [gluegen] at com.sun.gluegen.opengl.GLConfiguration.javaPrologueForMethod(GLConfiguration.java:120) [gluegen] at com.sun.gluegen.JavaEmitter.generatePublicEmitters(JavaEmitter.java:346) [gluegen] at com.sun.gluegen.JavaEmitter.generateMethodBindingEmitters(JavaEmitter.java:625) [gluegen] ... 5 more [gluegen] Exception occurred while generating glue code. Exiting. ------------ GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.11" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="javac"
fyi, there's an ebuild for jogl 1.1.1 in the java overlay now. kudos to alistair! the thing works for me(tm); well, i'd rather say it compiles. didn't have the chance to really put it to the test yet, but you guys might wanna try. cheers, nico
(In reply to comment #23) > fyi, there's an ebuild for jogl 1.1.1 in the java overlay now. kudos to > alistair! the thing works for me(tm); well, i'd rather say it compiles. didn't > have the chance to really put it to the test yet, but you guys might wanna try. > > cheers, > nico > I tested the a few of the demo apps and they all worked. Believe one app didn't work perfectly with black boxes in some areas. To note, the issue was jogl seems very pedantic about which version of gluegen it is built against, I had bumped gluegen inadvertently breaking jogl, even tho there seems no api changes in the gluegen runtime. Would be interesting to see whether upgrading gluegen after jogl has been built will still work.
The following thread chronicles my attempt to get Java OpenGL Acceleration working in a Java Applet called Runescape: http://forums.gentoo.org/viewtopic-t-827856-highlight-.html After installing dev-java/gluegen and this dev-java/jogl from the java-overlay overlay and making some additions to Java's runtime parameters via the Java Control Panel, I was able to enable hardware acceleration. The specific parameters were: -classpath "/usr/share/jogl/lib/jogl.jar:/usr/share/gluegen/lib/gluegen-rt.jar" -Djava.library.path="/usr/lib/gluegen/:/usr/lib/jogl/" After doing this, my system works perfectly with this ebuild emerged. I suggest that a minor changes be made to this ebuild such that it will add itself to the default class path and java library path for all users on a system upon installation and remove itself upon uninstallation. This is assuming that there are hooks for doing that in the jdk. If there are no such hooks, then the ebuild should be modified to append a warning with instructions to manually modify the Java Control Panel's runtime parameters field to append the appropriate jar file and directory to the class and library paths respectively.
Created attachment 239105 [details] dev-java/jogl-1.1.1a ebuild - fails to build A new stable release is out called 1.1.1a. Wikipedia says that it "fixes a critical buffer overrun issue". Version bumping the ebuild does not work because the version number string occurs twice in the url and one occurrence is hard-coded. I modified the ebuild to soft code the version number string and attached it. Unfortunately, a java runtime error occurs during the build: java.generate.gl: [echo] Generating GL interface and implementation [gluegen] WARNING: unable to find #include file "inttypes.h" [gluegen] WARNING: unable to find #include file "inttypes.h" [gluegen] WARNING: unable to find #include file "stdint.h" [gluegen] WARNING: unable to find #include file "stdint.h" [gluegen] java.lang.RuntimeException: Error while emitting binding for "glGetTexImage" [gluegen] at com.sun.gluegen.JavaEmitter.emitFunctions(JavaEmitter.java:292) [gluegen] at com.sun.gluegen.GlueGen.run(GlueGen.java:283) [gluegen] at com.sun.gluegen.GlueGen.main(GlueGen.java:297) [gluegen] Caused by: java.lang.IllegalArgumentException: Unmatched braces in the pattern. [gluegen] at java.text.MessageFormat.applyPattern(MessageFormat.java:476) [gluegen] at java.text.MessageFormat.<init>(MessageFormat.java:350) [gluegen] at com.sun.gluegen.JavaMethodBindingEmitter.emitPrologueOrEpilogue(JavaMethodBindingEmitter.java:380) [gluegen] at com.sun.gluegen.JavaMethodBindingEmitter.emitBody(JavaMethodBindingEmitter.java:367) [gluegen] at com.sun.gluegen.FunctionEmitter.emit(FunctionEmitter.java:102) [gluegen] at com.sun.gluegen.FunctionEmitter.emit(FunctionEmitter.java:111) [gluegen] at com.sun.gluegen.JavaEmitter.emitFunctions(JavaEmitter.java:290) [gluegen] ... 2 more [gluegen] Exception occurred while generating glue code. Exiting. I did diffs on the relevant files between versions 1.1.1 and 1.1.1a and I could not find the cause of the issue. If anyone wants to take a look, the relevant files can be found in: /var/tmp/portage/dev-java/jogl-1.1.1a/work/gluegen/src/java/com/sun/gluegen/ It appears to be building gluegen despite a patch to make it use the system gluegen. It is failing during the build of gluegen.
Created attachment 262385 [details] Working ebuild I figured this out shortly after I posted my "broken" ebuild, but I did this in the course of troubleshooting a different issue, so I forgot to post my findings. Installing jogl 1.1.1a requires doing a revision bump of gluegen. Otherwise the build will fail. I am uploading a "new" ebuild, which really is just the same ebuild that I posted originally modified to force gluegen to be the later version. The later version can be obtained by doing a revision bump, but some hops need to be done to obtain a tarball that is usable by the ebuild. I will post instructions on how to do that in bug #170305 shortly.
Added ebuilds for gluegen and jogl 2.0_rc8 to ::java-overlay. Both ebuilds are rough around the edges and need some more love. Anyway please test them and file bugs as necessary.
*** Bug 496872 has been marked as a duplicate of this bug. ***
Created attachment 410034 [details] jogl-2.3.1.ebuild version bump 2.3.1 using sources instead precompiled plugin3 remember to install gluegen-2.3.1 as well!
commit 7335188 (HEAD, master) Author: Patrice Clement <monsieurp@gentoo.org> Date: Fri Oct 23 15:15:12 2015 +0000 dev-java/jogl: Removing from overlay. Fixes bug 330267. Signed-off-by: Patrice Clement <monsieurp@gentoo.org> delete mode 100644 dev-java/jogl/Manifest delete mode 100644 dev-java/jogl/files/1.1.0/fix-solaris-compiler.patch delete mode 100644 dev-java/jogl/files/1.1.0/uncouple-gluegen.patch delete mode 100644 dev-java/jogl/jogl-1.1.1.ebuild delete mode 100644 dev-java/jogl/jogl-2.0_rc8-r1.ebuild delete mode 100644 dev-java/jogl/metadata.xml As pointed out in another bug, there's a MUCH up-to-date and looked-after version sitting in the Science Overlay. https://gitweb.gentoo.org/proj/sci.git/tree/dev-java/jogl Why does this ebuild end up in two overlays? We even have a version of gluegen in the Java Overlay. https://gitweb.gentoo.org/proj/java.git/tree/dev-java/jogl https://gitweb.gentoo.org/proj/java.git/tree/dev-java/gluegen Duplicate efforts which are totally useless IMHO. Anyway. Is there a *need* to add jogl to Portage? If yes, please file a new bug. I will look into adding it (as well as gluegen). Thank you.
Disregard the two links in the previous message. https://gitweb.gentoo.org/proj/java.git/tree/dev-java/gluegen https://gitweb.gentoo.org/proj/sci.git/tree/dev-java/gluegen
