Code review request: 7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so
stuart.marks at oracle.com
Tue Sep 25 22:19:10 UTC 2012
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
>> 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:
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
The alternative may be to stop trying to run 32-bit tests on the
More information about the core-libs-dev