HP-UX Patch for JSR231 JOGL 1.0.0-beta3

OpenGL Development JOGL Development
#1

The attached patch enables building of JOGL on HP-UX 11.11 (PA-RISC 2.0), using HP’s “aCC” compiler. Here’s an overview of what I changed:

  • Updated gluegen files gluegen-cpptasks.xml, StructLayout.java, and CPU.java to detect and flag HP-UX.
  • Updated jogl’s build.xml file for the platform, including linker and compilation settings for HP’s “aCC” (which the ant <cc> task already had support for). I tried getting the build to work with gcc but didn’t make much progress (which may have had more to do with my install of gcc than the platform… not sure).
  • Added _HPUX preprocessor directive to glx-CustomCCode.c to ignore xf98vmode.h (like Solaris).
  • Added macro definitions for RTLD_DEFAULT to glx-CustomCCode.c and InternalBufferUtils.c, as HP-UX doesn’t define that macro (used in calls to dylsym). Taking a cue from other projects, defining it to NULL seems to elicit the desired behavior on HP-UX (incidentally, I learned that RTLD_DEFAULT is not an official part of the POSIX standard, but only considered a reserved name).
  • Via _HPUX preprocessor test, modified InternalBufferUtils.c to (like Solaris) to use a proxy for the extension function glXGetProcAddressARB, using dlsym instead.
  • Added _HPUX to the preprocessor test in JAWT_DrawingSurfaceInfo.c for defining platformDSIClassName.

Some notes on the experience:

  • The glugen file CPU.java caused me some confusion, as it claims to be there as a check for 32/64 bit architectures, but HP-UX/PA-RISC2.0 (and apparently Solaris/SPARC) need to be marked as 32 bit, despite their 64 bit capabilities. Otherwise, structure unpacking doesn’t work (e.g. XVisualInfo). The abstraction should convey something about specific data type sizes rather than general architecture (is it there for native pointer sizes?). Overall, there’s opportunity for some nice refactoring across the source via a “PlatformProperties” type of class. The number of calls to System.getProperty("os.name") should be of long-term concern, particularly some of the ones for MacOS X specific code. I’d be open to taking a stab at such a class if there is interest. Let me know.
  • I’m guessing the use of glXGetProcAddressARB–an OpenGL 1.3 feature–is used as the default mechanism for OpenGL function pointer lookup over dlsym because it’s more specific to the task. But I’d argue, for the sake of true OpenGL 1.1 compliance, that dlsym should be used throughout the X11 implementation to eliminate hacks for HP and Sun (supported on Linux and FreeBSD via xf86/Mesa)?? But then again, I don’t know the design history here.
  • My installation of HP-UX required me to add libjvm.so (and the search directory for it) to linking of libjogl_awt.sl. Otherwise the platform linker got confused and looked for it in the wrong place. My version of Java is 1.4.2_10-b03. The modification in build.xml for this may or may not be neccessary in the long term.

I hope someone else finds this helpful. There’s a 50/50 chance I’ll need to repeat this exercise for SGI/IRIX, so hopefully the process will be quicker for me.

Ken, thanks for all yoru help! You really gave me the clues I needed! Let me know if other changes are neccessary before it’s considered for inclusion in the versioned source.

Simeon

#2

Thanks for the patch. The essential parts have been applied to the main source tree. Please let me know if it looks like anything was broken during the merge.

Sorry for the confusion. The CPU class really indicates the data model of the currently-running Java process as opposed to the support the processor provides. I’ve just checked in an update to the javadoc to try to clarify this.

Note as an example that a 32-bit JVM running on an UltraSPARC processor will report os.cpu as “sparc”, while a 64-bit JVM on the same processor will report “sparcv9”.

#3

Looks like the merge worked prefectly, as tested against last night’s CVS state. Many thanks again!

Ah… I didn’t realize there was a distinction. In case this ever comes up again, when I run the HP-UX JVM in default (32 bit) mode, I get:

  • os.name=HP-UX
  • os.arch=PA_RISC2.0
  • sun.arch.data.model=32
  • sun.cpu.isalist=pa2.0 pa1.2 pa1.1 pa1.0

when I run it in 64 bit mode (with the -d64 flag), I get:

  • os.name=HP-UX
  • os.arch=PA_RISC2.0W
  • sun.arch.data.model=64
  • sun.cpu.isalist=pa2.0 pa1.2 pa1.1 pa1.0

So the distinction is as with SPARC/Solaris.

Simeon

#4

Thanks for this great work!

Will the libraries (binaries) be available for download like the Linux or Windows natives?

/Jonas

#5

We don’t have the hardware or resources to include HP-UX natives with our nightly builds. If at the point the RI is finalized someone would like to contribute native libraries for HP-UX, we’ll be glad to include them with the Java Web Start installation. (In fact, if you’d like to to this even for intermediate builds such as beta 4 we’ll update the JNLP files.)