GCC Bugzilla – Bug 17831
GCJ/CNI should be usable without 'gcjh'
Last modified: 2005-09-30 05:30:47 UTC
A nice enhancement to GCJ would be to remove the need to invoke 'gcjh' on
compliled classes before compiling CNI C++ source. Extending this to JNI code
would be nice, too, but potentially harder.
That is, the following command line should work:
$ gcj -shared -o lib-foo.so foo.java foo.cc
Or, even this exact sequence:
$ gcj -c -o foo.o foo.java
$ gcj -c -o foo-cni.o foo.cc
$ gcj -shared -o lib-foo.so foo.o foo-cni.o
In theory this should be possible, since everything you need to compile to
'lib-foo.so' is present in those two files. But in practice, of course, this
touches potentially everything from g++ to cpp, and becomes pretty hairy indeed.
Maybe a good way to do this would be to extend cpp so front-ends can register
hooks to the include-lookups, so gcj could, for example, intercept certain
#includes to produce CNI headers on-the-fly.
Also, gcj/gcjh should be able to generate CNI/JNI headers from java source. gcjx
can (will be able to) do this, for example.
Well the easy way to do this is to create the headers while compiling, aka combine gcj and gcjh like gcjx
Yes, but gcj doesn't have this feature currently, and gcjh only works with
bytecode. In the least it should work with java source, too.
In my opinion being able to generate CNI headers along with the compilation step
would be invaluable in itself.