Close to having HP-UX port; need help with extensions

OpenGL Development JOGL Development
#1

I am tantilizingly close to patching the build scripts for an HP-UX 11.11 port of the JOGL 1.0.0-beta3 release, but have gotten stuck managing some extensions that aren’t available on this system.

Specifically I’m getting an error for the binding to glXAllocateMemoryNV, which confusingly is declared as “ignored” in glx-x11.cfg:


       [cc] aCC -Ae +W942 -c +z -D__RISC2_0__ -I/opt/Mesa/include -I/homes/sfitch/hp/jogl/jogl/make/stub_includes/opengl -I/opt/java1.4/include -I/opt/java1.4/include/hp-ux /homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLXExtImpl_JNI.c /homes/sfitch/hp/jogl/jogl/src/native/jogl/InternalBufferUtils.c /homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLX_JNI.c /homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLImpl_JNI.c /homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLU_JNI.c
       [cc] /homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLXExtImpl_JNI.c:
       [cc] Error 419: "/homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLXExtImpl_JNI.c", line 31 # 'PFNGLXALLOCATEMEMORYNVPROC' is used as a type, but has not been defined as a type.
       [cc] /homes/sfitch/hp/jogl/jogl/src/native/jogl/InternalBufferUtils.c:
       [cc]       PFNGLXALLOCATEMEMORYNVPROC ptr_glXAllocateMemoryNV;
       [cc]       ^^^^^^^^^^^^^^^^^^^^^^^^^^
       [cc] Error 419: "/homes/sfitch/hp/jogl/jogl/build/gensrc/native/jogl/GLXExtImpl_JNI.c", line 33 # 'PFNGLXALLOCATEMEMORYNVPROC' is used as a type, but has not been defined as a type.
       [cc]       ptr_glXAllocateMemoryNV = (PFNGLXALLOCATEMEMORYNVPROC) (intptr_t) procAddress;
       [cc]                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^

Shouldn’t line 59 in glx-x11.cfg (Ignore glXAllocateMemoryNV) keep gluegen from emitting this function? Is there some other gluegen configuration that is triggering a dependency?

Is there a way get gluegen to log its evaluation of the configuration rules?

Any tips on this and the finer points of gluegen would be really appreciated, as well as anyone who has successfully ported JOGL to HP-UX and/or SGI/IRIX.

Simeon

PS:

What’s the best way for introducing gluegen statements for HP-UX only? Would I create and bind a a “gl-x11-hpux.cfg” file which then inlcudes “gl-x11.cfg”?

#2

It’s great to see efforts to get JOGL to work on more platforms. Sorry for the confusion around the build process.

This area is a bit confusing. There is a distinction between the core GLX routines, which are used for OpenGL context management, and the GLX extensions, which are exposed as a separate object and used for things like pbuffer creation. A similar distinction exists between WGL and WGLExt on the Windows platform and CGL and CGLExt on the OS X platform (although CGL is a bit of a misnomer in this case, and there are currently no functions in CGLExt).

The configuration file you want to look at is glxext.cfg, which is used to produce GLXExt.java. Note that this configuration file ignores the core GLX routines, so as to produce only the GLX extension functions into GLXExt.java.

Incidentally, you should not need to ignore this extension. Note that JOGL compiles its generated C sources against its own GL/gl.h, GL/glext.h and GL/glxext.h header files, and calls possibly-unsupported routines like this one only through function pointers. This means that you don’t need an implementation of this routine on your particular platform in order to make things work. As a matter of fact, I’m a little surprised you ran into a build problem in this area at all unless you’ve made other changes to the build process. I wonder whether a problem may be that you need to pass something like -nostdinc to your C compiler using cpptasks so that it picks up JOGL’s gl.h header files instead of ones in /usr/include/GL. This hasn’t been a problem on any other platform, though.

Probably the best way to get this information is to run “ant -v” and pipe the output to a file. That will show for example exactly how GlueGen is being invoked for each portion of the code generation.

You might want to take a look at the GlueGen manual at some point, although it isn’t directly relevant to your task at hand, if you’re interested in how the various .cfg file directives work. Please provide feedback on it and on the tool in general.

Perhaps. It really depends on what changes you need to make. Take a look at the FreeBSD-related targets in the build.xml and note that no FreeBSD-specific changes were necessary to get JOGL to build on that platform. If you post a set of your diffs perhaps we can offer some advice on what is and is not strictly necessary in order to get things to build. We’d be glad to take back any changes you have once things are working so that the unmodified JOGL sources will build cleanly on HP-UX.

#3

Ahh… this is a key clue. For some reason (I’ve now forgotten) I added the include path to the system OpenGL libraries to build.xml. I just completed a successful compile and link (after some other tweaks).

Thanks for the informatively detailed and helpful response. I’ll post a patch set once I ensure the demos are working.

Simeon

#4

Arg! So close!

Everything complies and links, but when I try to run demos.gears.Gears, I get the following error:

/usr/lib/dld.sl: Unresolved symbol: glXGetProcAddressARB (code) from /homes/sfitch/hp/jogl/jogl/build/obj/libjogl.sl

All the necessary libraries are in my SHLIB_PATH, and doing an nm on libGL.sl confirms that this symbol isn’t defined in the system libraries (output below).

I investigated putting an “Ignore” statement in glx-x11.cfg, but saw this function is handled in a different manner:


# This must be present for bootstrapping
SkipProcAddressGen glXGetProcAddressARB

I checked the gluegen manual on this declaration, but can’t say I quite understand the difference between it an “Ignore”. Are any details available on what this does for the JOGL build?

Any other hints come to mind?

Many thanks!

Simeon

Output from nm:

nm -P /opt/graphics/OpenGL/lib/libGL.sl | grep glX
_hpInit_glXChooseVisual t 00019710
_hpInit_glXChooseVisual t 00019710
_hpInit_glXCopyContext t 00019788
_hpInit_glXCopyContext t 00019788
_hpInit_glXCreateContext t 00019808
_hpInit_glXCreateContext t 00019808
_hpInit_glXCreateGLXPixmap t 00019888
_hpInit_glXCreateGLXPixmap t 00019888
_hpInit_glXDestroyContext t 00019900
_hpInit_glXDestroyContext t 00019900
_hpInit_glXDestroyGLXPixmap t 00019970
_hpInit_glXDestroyGLXPixmap t 00019970
_hpInit_glXGetClientString t 000199e0
_hpInit_glXGetClientString t 000199e0
_hpInit_glXGetConfig t 00019a50
_hpInit_glXGetConfig t 00019a50
_hpInit_glXGetCurrentContext t 00019ac0
_hpInit_glXGetCurrentContext t 00019ac0
_hpInit_glXGetCurrentDisplay t 00019ac8
_hpInit_glXGetCurrentDisplay t 00019ac8
_hpInit_glXGetCurrentDrawable t 00019ad0
_hpInit_glXGetCurrentDrawable t 00019ad0
_hpInit_glXIsDirect t 00019ae8
_hpInit_glXIsDirect t 00019ae8
_hpInit_glXMakeCurrent t 00019b58
_hpInit_glXMakeCurrent t 00019b58
_hpInit_glXQueryExtension t 00019bd0
_hpInit_glXQueryExtension t 00019bd0
_hpInit_glXQueryExtensionsString t 00019c48
_hpInit_glXQueryExtensionsString t 00019c48
_hpInit_glXQueryServerString t 00019cb8
_hpInit_glXQueryServerString t 00019cb8
_hpInit_glXQueryVersion t 00019d30
_hpInit_glXQueryVersion t 00019d30
_hpInit_glXSwapBuffers t 00019da8
_hpInit_glXSwapBuffers t 00019da8
_hpInit_glXUseXFont t 00019e08
_hpInit_glXUseXFont t 00019e08
_hpInit_glXWaitGL t 00019e10
_hpInit_glXWaitGL t 00019e10
_hpInit_glXWaitX t 00019e18
_hpInit_glXWaitX t 00019e18
_hpInit_hpglXDisplayIsVGL t 00019e30
_hpInit_hpglXDisplayIsVGL t 00019e30
_hpOGL_hpglXDisplayIsVGL t 00018df0
_hpOGL_hpglXDisplayIsVGL t 00018df0
glXChooseVisual T 00020ee8
glXChooseVisual U
glXChooseVisual T 00020ee8
glXCopyContext U
glXCopyContext T 00020f60
glXCopyContext T 00020f60
glXCreateContext T 00020fe8
glXCreateContext T 00020fe8
glXCreateContext U
glXCreateGLXPixmap U
glXCreateGLXPixmap T 00021070
glXCreateGLXPixmap T 00021070
glXDestroyContext T 000210f0
glXDestroyContext U
glXDestroyContext T 000210f0
glXDestroyGLXPixmap T 00021168
glXDestroyGLXPixmap U
glXDestroyGLXPixmap T 00021168
glXGetClientString T 000211e0
glXGetClientString T 000211e0
glXGetClientString U
glXGetConfig U
glXGetConfig T 00021258
glXGetConfig T 00021258
glXGetCurrentContext T 000212e0
glXGetCurrentContext T 000212e0
glXGetCurrentDisplay T 00021348
glXGetCurrentDisplay T 00021348
glXGetCurrentDrawable T 000213b0
glXGetCurrentDrawable T 000213b0
glXIsDirect U
glXIsDirect T 00021418
glXIsDirect T 00021418
glXMakeCurrent T 00021490
glXMakeCurrent U
glXMakeCurrent T 00021490
glXQueryExtension T 00021510
glXQueryExtension U
glXQueryExtension T 00021510
glXQueryExtensionsString T 00021590
glXQueryExtensionsString T 00021590
glXQueryExtensionsString U
glXQueryServerString U
glXQueryServerString T 00021608
glXQueryServerString T 00021608
glXQueryVersion T 00021688
glXQueryVersion U
glXQueryVersion T 00021688
glXSwapBuffers T 00021708
glXSwapBuffers T 00021708
glXSwapBuffers U
glXUseXFont T 00021780
glXUseXFont T 00021780
glXWaitGL T 00021808
glXWaitGL T 00021808
glXWaitX T 00021870
glXWaitX T 00021870
hpglXDisplayIsVGL T 000218d8
hpglXDisplayIsVGL U
hpglXDisplayIsVGL T 000218d8
#5

After further digging it seems that my issue is very similar to one on AMD64 Linux commented on in X11GLDrawableFactory.java (line 56), which states:

// There is currently a bug on Linux/AMD64 distributions in glXGetProcAddressARB

When I add a similar hack to the code for HP-UX my code runs further, (to a different problem in GLX.XGetVisualInfo which I’ve yet to investigate; backtrace below).

I tried to do some digging to determine the OpenGL ARB version status of this function, and really only found this:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.txt
which implies that it’s a OpenGL 1.3 feature.

This begs the question: What is the minimum version of OpenGL JOGL will require (I’ve not read the JSR yet)? The HP-UX box I have access to currently only has OpenGL 1.1. If OpenGL 1.1 on X11 is to be supported (please?), should a bug be filed against X11GLDrawableFactory.dynamicLookupFunction(String)?

I’m also concerned about X11GLDrawableFactory.loadGLULibrary() which has a hardcoded path to libGLU defined as /usr/lib/libGLU.so. I guess Linux and Solaris put the file there (and both use the .so extension), but HP-UX does’t (and uses the *.sl extension). Any thoughts about this? Seems that this would also inhibit a user from overriding default libraries via an LD path.

On to the next issue.

Simeon

Current stumbling block: 

Exception in thread "main" java.lang.IllegalArgumentException
        at java.nio.Buffer.limit(Buffer.java:249)
        at com.sun.opengl.impl.x11.GLX.XGetVisualInfo(GLX.java:349)
        at com.sun.opengl.impl.x11.X11GLDrawableFactory.chooseGraphicsConfiguration(X11GLDrawableFactory.java:143)
        at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:113)
        at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:82)
        at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:75)
        at demos.gears.Gears.main(Gears.java:19)
#6

Current diff attached in case it’s informative…

#7

Also see the hack in src/native/jogl/InternalBufferUtils.c. You may want to change the #ifdef there to include HP-UX as well as Sun.

[quote]This begs the question: What is the minimum version of OpenGL JOGL will require (I’ve not read the JSR yet)? The HP-UX box I have access to currently only has OpenGL 1.1. If OpenGL 1.1 on X11 is to be supported (please?), should a bug be filed against X11GLDrawableFactory.dynamicLookupFunction(String)?
[/quote]
JOGL should work with OpenGL 1.1 implementations (it works fine on Windows with the old Microsoft software renderer which only supports 1.1), and should work on older (pre-1.3) GLX implementations as well. Try the above hack to see whether it also gets you past the glXGetProcAddressARB issue.

Feel free to change this to just libGLU.so and to add in a helper routine to compute the suffix which would return .sl on HP-UX and .so on all other Unices.

You may want to hack the generated glue code (which you can do; it shouldn’t be blown away during a rebuild if you do) to see what the state of that Buffer is before the call to limit().