From: Andrew R. <and...@us...> - 2007-11-14 22:52:32
|
On Wed, Nov 14, 2007 at 01:33:05PM -0800, Alan Irwin wrote: > On 2007-11-14 13:54-0000 Andrew Ross wrote: > > You didn't mention the sablevm package version you were running. Mine is > 1.13-1.1. I can confirm for that version that the build works fine, but > ctest fails with exactly the above error message so I think you must have > the same (limited) version. > > > > >So from a free point of view it looks like the best option for now is to > >use the gij version of java, or if your conscience allows go for one of > >the versions based on Sun's sdk. > > Here is my assessment of PLplot java on Debian/Ubuntu. You have proved > three different java implementations build and ctest fine, and two others > (jikes-kaffe and free-java-sdk which depends on jikes-sablevm and sablevm) > build fine, but have ctest problems. I believe that shows there are > deficiencies in the kaffe and sablevm java virtual machine implementations > which you should avoid by putting in specific build and run-time dependences > in your Debian packages. > > For now, I am following my own advice. I have just run > > apt-get --purge remove free-java-sdk > apt-get autoremove #To remove free-java-sdk dependencies > apt-get install gij, gcj, fastjar You might like to look at the java-gcj-compat and java-gcj-compat-dev packages which bundle all this together with symlinks and scripts to provide a java sdk like environment. > > One of the dependencies of gij is libgcj8-dev. That installs jni.h in > /usr/lib/gcc/x86_64-linux-gnu/4.2/include for some strange reason. About a > zillion different Debian packages provide jni.h (some of them in more > standard locations). But if you do not have those other packages installed, > then you must > > export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.2/include > > (or whatever is appropriate for your hardware platform) to get gij to work. The whole jni thing is a mess. Automatically finding this is not easy. There seems to be little consistency. I'd rather see things in package` specific directories so you can switch between java compilers just by changing JAVA_HOME. Alas this is not to be.... > > After I made the above changes, java built and passed ctest without issues. > Furthermore, if you run > > (for INDEX in ls x*j.psc |sed -e "s?x??" -e "s?j.psc??"; do echo $INDEX; \ > diff x${INDEX}[cj].psc; done) |less > > in the test directory you will see all java examples give the same results > as the C examples except for example 21 (which you may have mentioned > before). > > To summarize the Java issues: > > (1) Doesn't ctest on some Debian java platforms. Andrew, could you please > file the appropriate Debian bug reports for kaffe and sablevm? I also > suggest you change the Debian dependencies in the Debian packaging effort > you are in charge of to avoid those platforms, but that (downstream) > packaging effort is not critical to our (upstream) release. On my list to do. > (2) Example 21 does not produce results that are consistent with the C > results. If you cannot come up with any quick fixes, that is something we > can deal with post-release. I'll take a look. Are you sure this is not just the fact that example 21 has a randomly generated data set in it? > (3) The library naming problem Hazen found on Mac OS X (see his recent post > to this list). To my mind that is the only release-critical issue left for > Java. Andrew, can you come up with a quick CMake fix for that? Hm. I'll have a think. Andrew |