RFR (M): 8024265: Enable new build on AIX (top level part)

[Magnus Ihse Bursie]

Hi Volker,

Most of the changes look good. Thank you for the general house-keeping 
of shared code!

Some comments inlined:

> common/autoconf/build-aux/config.guess
>
> On AIX 'config.guess' may return 'powerpc' as architecture but 'powerpc' is
> implicitly handled as 32-bit architecture in 'platform.m4' so we always set
> it to 'rs6000' which we then map to 'ppc64' in 'platform.m4'.

We already have a case for powerpc64 in platform.m4 (which I think was 
put there as a placeholder for future development, i.e. what you are 
doing right now :-)). Is there any reason why config.guess should not 
return that, rather than rs6000? Apart from minimizing the changes in 
platform.m4, at least to me powerpc64 is more comprehensible than rs6000.

> Added new variable COMP_MODE_OPTION to hold the option name for the
> 32/64-bit compiler parameter which is -m on the current OpenJDK platforms
> but -m for xlc on AIX.

(I think you mean that it is -q for xlc)

Ahrgh, all these proud compilers with their own ways of expressing the 
same functionality. :( I assume that you are using the COMP_MODE_OPTION 
in the jdk projct? I couldn't find any references to it in the Hotspot 
build changes, and otherwise there seems to be no reason to export it in 
the spec.gmk file.

First of all, I think you should have a look at the function 
PLATFORM_SET_COMPILER_TARGET_BITS_FLAGS in platform.m4, and how it is 
called from PLATFORM_SETUP_OPENJDK_TARGET_BITS. I believe the proper way 
forward is to do as we do on Solaris, and always set the -q flag. Your 
current solution requires, as you say, the -q64 to be passed as extra 
flags to the configure command line, and that's not really the way it is 
supposed to work.

Unfortunately, I'm afraid that just fixing these two functions won't 
suffice, since there are likely a few -m sprinkled around the code. So 
we're back to having the -m/-q being a variable. However, I'm not very 
fond of the name. "Compare mode what?" was my first reaction. If it is 
supposed to be a shorthand for "compiler mode", I think it's too vague. 
Compilers can have many modes. I don't have a good replacement name, but 
since it is used to prefix OPENJDK_TARGET_CPU_BITS, something along 
these lines would problably make it more clear what it is about.


> common/autoconf/toolchain.m4
>
>     - Detect xlc compiler version on AIX.
In case of failure, this does:
   AC_MSG_ERROR([Failed....])
without any context to the poor user about what failed. Please write a 
more descriptive error message, along the lines of "Failed to determine 
xlc compiler version" or so.

> common/makefiles/JavaCompilation.gmk
>
>     - Replace xargs by wc for the task of "..trim the whitespace from the
>     contents file, to see if it is empty.." because xargs has problems on
>     AIX and wc should work just as well if not even better on any other
>     OpenJDK platform.

The change itself looks good, but you added a comment:

  (xargs has problems on AIX and seems oversized for this task anyway:)

which only refers to old, removed code, so it wouldn't make any sense if 
your patch is applied. Such a comment will confuse the reader rather 
than help, I think, and would be better removed.

> common/makefiles/NativeCompilation.gmk
>
> Fixed usage of AR_FLAGS which does not exist as variable by replacing it
> with the existing ARFLAGS.
Good catch! It seems we've never been using ARFLAGS at all, which is a 
bit worrying. I wonder what this does for the existing platforms, now 
that we (potentially) start sending ar a bunch of flags...

/Magnus