> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/
make/solaris/Makefile
No comments.
make/solaris/makefiles/buildtree.make
No comments.
A product build with the above changes shows this:
$ cat solaris_amd64_compiler2/product/mapfile_ext
# Extended set of symbols.
JVM_SetVmMemoryPressure;
Looks right to me.
Dan
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:
http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/
/Jesper
Daniel D. Daugherty skrev 21/8/14 18:42:
On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote:
Hi,
On Solaris the HS_ALT_MAKE variable was not passed to vm.make when
creating
the mapfiles which lead to mapfile-ext not being found and later a
linker
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.
Webrev:
http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/
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
examples.
Dan
Bug:
https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110
This is a P1 so if you feel comfortable with the hotspot makefiles,
please
have a look.
Thanks!
/Jesper
