javah output file naming weirdness

[Andrew John Hughes]

2008/4/28 Alan Bateman <Alan.Bateman at sun.com>:
> Andrew John Hughes wrote:
>
> > We recently uncovered a bug in the JikesRVM
> > (http://jira.codehaus.org/browse/RVM-456), namely that we were relying
> > on the naming of the header files generated by javah being in the same
> > style as those generated by the proprietary Sun JDK.
> >
> > As can be seen in the bug report, the breakage showed up when using
> > IcedTea6/OpenJDK6 to build JikesRVM.  On OpenJDK6,
> >
> > javah -verbose -d
> > /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/c
> > -classpath
> /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/jksvm.jar
> > org.jikesrvm.scheduler.greenthreads.VM_Process
> >
> > produces a file named:
> >
> > org_jikesrvm_scheduler_greenthreads_VM_Process.h
> >
> > while apparently the proprietary version emits:
> >
> > org_jikesrvm_scheduler_greenthreads_VM_0005fProcess.h
> >
> > (encoding the classname's underscore character as 0005f).  We fixed
> > our bug by explicitly asking for javah to emit the latter named file,
> > but is this a regression in the OpenJDK6 version of javah?  Even the
> > OpenJDK I was using before (b12) still emitted the 0005f version (at
> > least I presume so, because the build worked...)
> >
> > Any ideas?
> >
> >
>  I'm not involved in this area but I suspect this is related to the re-write
> of javah in 1.4.2. I just did a quick test with 1.4.2 to check and it emits
> the header file as VM_0005fProcess.h. Running 1.4.2's javah with an
> undocumented -Xnew option to select the "new" version causes it to emit
> VM_Process.h which is what 5.0 and newer also emits (the new version became
> the default in 5.0).  Is there any possibility you've been building JikesRVM
> with a 1.4.2 or older release? When you say that the OpenJDK javah was
> generating the 0005f version then are you sure? Any possibility the build
> worked because it was picking up a header from a previous build with 1.4.2
> or older?
>
>  -Alan.
>

Alan,


Thanks for your input.

The problem was that my javah from OpenJDK6 was _not_ emitting the
0005f that JikesRVM was relying on.
If this truly has not been the default since 1.4, then the fact that
the previous build worked for people
like Ian using the proprietary 1.6 JDK is very odd.

Personally, I've never had a copy of 1.4.2 or any of the other
proprietary JDKs on my system, and have thus only built JikesRVM using
OpenJDK builds.
It is of course possible that there is something in the tree from older JDKs.

However, from working with the langtools code myself, I do remember
there being two versions of javah.
Ant is presumably calling javah programmatically (i.e. via com.sun
rather than via the command line version)
and so could of course be using the old API even in 1.5 and above.
This suggests that either OpenJDK6
produces the new version even from the old API, or that later versions
of Ant have switched to using the
newer API.

Ian, which version of Ant do you use to build?

Thanks,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8