On 9/25/12 12:58 AM, Alan Bateman wrote:
On 25/09/2012 05:16, Weijun Wang wrote:
Hi Stuart
Please take a look at
http://cr.openjdk.java.net/~weijun/7200682/webrev.00/
So I am now using "java -XshowSettings:properties | grep os.arch" to find out
the arch. Not sure if there is a more formal way to do that.
An alternative might be to look at the OS_ARCH field in the "release" file The
intention with that file is that there is somewhere in the image that IDEs,
tools, tests, etc. can look at without needing to run "java". The other issue
might be the development environment where you are running tests on a
non-images build and so the release file won't exist.
The change looks like it does what it's intended to do, but it seems like there
ought to be a better way to do this. Surely we don't expect every shell script
to dig around and find the right paths to architecture-specific libraries, do we?
I haven't looked too closely at the multiarch stuff, and aside from a bunch of
flamage on Ubuntu forums, I did find this:
https://wiki.ubuntu.com/MultiarchSpec
It seems mostly about packaging and filesystem layout. I recall seeing
somewhere that toolchains are expected to choose the right paths, so that one
can install properly-constructed packages without regard to architecture (even
installing both flavors on the same machine) and things should "just work."
What I couldn't find is a way for a running process to detect which
architecture it is, so that it can look in the right place in the filesystem
for architecture-specific files. Maybe there's a way to do this, I just haven't
found it. Either that or the multiarch scheme isn't fully fleshed out.
Meanwhile I don't think it's reasonable to try to put this logic into the shell
script tests. They're bad enough already with the OS-specific logic that's done
slightly differently in each test. Adding multiarch stuff would make things
really messy.
The alternative may be to stop trying to run 32-bit tests on the
64-bit-multiarch systems.
s'marks
