Code review request: 7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so

[Stuart Marks]

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