RFR (s) 8135298: Fix zero builds for "unknown" architectures on linux.

[Matthias Klose]

On 17.09.2015 15:06, Magnus Ihse Bursie wrote:
> On 2015-09-17 14:48, Severin Gehwolf wrote:
>> Hi,
>>
>> On Thu, 2015-09-17 at 10:50 +0200, Magnus Ihse Bursie wrote:
>>> I'm not sure this code does what you think it does. At least when
>>> building from the top-level makefile, ZERO_LIBARCH will always be
>>> set,
>>> so the "unknown" case will not be reached.
>> CC'ing Matthias as we're not really building on any platform not
>> listed in platform.m4.
>>
>> Looking at common/autoconf/platform.m4 (line 20 onwards) where VAR_CPU
>> seems to be defined, then used as OPENJDK_TARGET_CPU and then as
>> OPENJDK_TARGET_CPU_LEGACY_LIB and yet again as ZERO_LIBARCH. It may be
>> true for all the CPUs listed in platform.m4. I can only speculate, but
>> some distributions still build on more platforms than listed there
>> (Debian?). So if some distribution patches that code to support a
>> specific arch, what happens then? Has this been considered when you
>> wrote the above?
>
> I can't really tell how the code behaves when additional patches I have not seen
> are laid on top of it. :-) However, I *can* see that in hotspot-spec.gmk
> ZERO_LIBARCH is *always* defined to have a value, so unless this is patched
> around as well, the "unknown" case will never be reached. Otoh, I'm not sure
> what that would mean either. The code is not likely to just happen to start
> running on an unknown architecture without some nontrivial effort. I just
> thought the code would do the same but more clearly if the fallback case just
> used OPENJDK_TARGET_CPU_LEGACY_LIB, instead of talking about zero and "unknown".

my intent was to provide a default value; if ZERO_LIBARCH can be used for that, 
then fine.

>>> Also, I'd like to hijacking this thread slightly, sorry about that.
>>> :)
>>>
>>> When rewriting the Hotspot makefiles, I've been wondering if it
>>> would
>>> not make more sense to consider "zero" to be a different
>>> architecture,
>>> rather than a different "flavor" (like minimal1), as it is treated
>>> right
>>> now. This patch seems to align with the treatment of zero as an
>>> architecture. Just as an open question, do you think that would make
>>> sense?
>> A Zero (interpreter only) JVM has the goal to be (easily) built on
>> many (any?) architectures. There can be Zero on x86_64, on arm32, etc.
>> I don't think it makes sense to treat Zero as an architecture itself.
>> To me it being a variant/flavor kind of build is correct (depending on
>> what the definition of a variant/flavor build is exactly).
> Ok, great! Thanks for your input.

right, although there architectures where neither hotspot nor zero builds 
(sparc, sparc64).