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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
