RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Aug 21 17:43:07 UTC 2014
A product build with the above changes shows this:
$ cat solaris_amd64_compiler2/product/mapfile_ext
# Extended set of symbols.
Looks right to me.
On 8/21/14 11:04 AM, Jesper Wilhelmsson wrote:
> Thank you for the quick reply Dan!
> A new webrev with your suggested change is available here:
> Daniel D. Daugherty skrev 21/8/14 18:42:
>> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote:
>>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when
>>> the mapfiles which lead to mapfile-ext not being found and later a
>>> error due to symbols declared in the extra mapfile not being found.
>>> The hotspot makefiles are .. interesting .. yes.
>>> The proposed solution is to include defs.make where HS_ALT_MAKE is
>>> set up into
>>> vm.make on Solaris.
>> Unfortunately, including defs.make in make/solaris/makefiles/vm.make
>> isn't the "right" way to get a top-level variable down into the
>> HotSpot build system. I cannot remember what breaks when you do that,
>> but it doesn't work right in all the ways that we build HotSpot.
>> For the HotSpot build system, you'll want to:
>> - update make/solaris/Makefile and add HS_ALT_MAKE to
>> the BUILDTREE_VARS list:
>> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE)
>> - update make/solaris/makefiles/buildtree.make and add
>> HS_ALT_MAKE to the rule that creates flags.make:
>> [ -n "$(HS_ALT_MAKE)" ] && \
>> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \
>> The way I usually find all the right spots is I look for
>> where ZIPEXE is added to the above files and follow those
>>> This is a P1 so if you feel comfortable with the hotspot makefiles,
>>> have a look.
More information about the build-dev