hotspot 32-bit on 64-bit "cross-compile" broken
David Holmes
david.holmes at oracle.com
Tue Sep 18 03:49:29 PDT 2012
On 18/09/2012 8:39 PM, Erik Joelsson wrote:
> On 2012-09-18 11:39, David Holmes wrote:
>>
>>> the hotspot makefiles changed recently (as in after the last build-infra
>>> push to jdk8), which caused the spec.gmk to get indirectly included
>>> again at a later stage, after gcc.make (and friends) have been
>>> evaluated.
>>
>> If something is being done incorrectly here let me know and I will fix
>> it. We are just about the push the minimal VM changes and that will
>> require a follow up to make build-infra recognize the minimal
>> JVM_VARIANT.
>>
>>
> I'm not sure if incorrect is the correct term. Here follows an
> explanation of what I think went wrong and why:
>
> In "7154641: Servicability agent should work on platforms other than
> x86, sparc", the following was added to saproc.make:
>
> include $(GAMMADIR)/make/defs.make
>
> saproc.make is in turn included by vm.make where I'm assuming the
> assembly compilation is taking place.
>
> ASFLAGS is defined in gcc.make using '='.
> In rules.make AS.S is defined as AS.S = $(AS) $(ASFLAGS)
>
> Now, since vm.make includes saproc.make, which includes defs.make, which
> includes spec.gmk, ASFLAGS gets overwritten, and since it's using lazy
> evaluation, AS.S is effectively changed too.
>
>
> I think the correct solution in this case was to not have configure and
> spec mess with ASFLAGS at all, and that's what I've done now.
Thanks for explaining that. The minimal VM changes also cause defs.make
to be included in a place it was not previously included
(buildtree.make). We will need to be wary of the potential for spec.gmk
to be included multiple times, possibly causing variables to be
unexpectedly overridden.
David
> /Erik
More information about the build-infra-dev
mailing list