[RFC] Fix Zero and Shark builds

David Holmes david.holmes at oracle.com
Thu Feb 21 04:15:37 PST 2013


On 21/02/2013 9:26 PM, Roman Kennke wrote:
> Am Donnerstag, den 21.02.2013, 21:17 +1000 schrieb David Holmes:
>> So far I've looked at the hotspot changes - but really this should also
>> go to hotspot-dev - cc'd
>>
>> I only see one change that isn't confined to zero/shark specific code
>> and that is in make/linux/makefiles/vm.make:
>>
>>     ifeq ($(JVM_VARIANT_ZEROSHARK), true)
>>       STATIC_CXX = false
>>     else
>> !   ifeq ($(OPENJDK_TARGET_CPU), ppc64)
>>         STATIC_CXX = false
>>       else
>>         STATIC_CXX = true
>>       endif
>>     endif
>>
>> this may conflict with the incoming AIX/ppc64 port.
>
> So far, the only supported ppc64 in Hotspot is Zero. At least to my
> knowledge. I am not sure why we need to explicitely link libstdc++
> dynamically there though. I don't really see how this could affect
> anything outside Zero. And yes, it probably does affect the upcoming
> PPC64 port, but this needs to be sorted out anyway.

Ok. Just wanted to flag it.

>> My other comment on these changes is that you've now made the zero
>> hotspot build dependent on being part of a complete build - ie there
>> must be a spec.gmk/hotspot-spec.gmk for these variables to be defined.
>> You won't be able to build hotspot stand-alone. Is that what you intended?
>
> Probably not. Not sure how a standalone hotspot build works with the new
> build-system. (I would be very happy to do this to reduce turnaround
> even more.) What would I need to do? Move all Zero/Shark variables to
> hotspot-spec.gmk.in ?

Hotspot has always been "self-configuring" on the build side. You can 
set a few variables to influence things but for the most part it detects 
things at build time. With the new build system hotspot was made 
"configure-aware". It was changed to include the spec.gmk file if it 
existed and the setting of variables potentially set by configure (and 
so in the spec.gmk file) was only done if not already set. Hence the two 
build approaches can co-exist.

I don't know how a zero build was previously initiated but I could 
imagine it was something like:

make ZEROARCH=zero <some-zero-target>

then the zero-target together with the ZEROARCH value would trigger the 
right build logic to  set all the necessary Zero flags. To maintain this 
you just need to be prepared for values to have been pre-set via spec.gmk.

David
-----


> Thanks,
> Roman
>
>



More information about the build-infra-dev mailing list