Mutiply defined symbol InlineSmallCode, globals.hpp, globals_zero.hpp

[Edward Nevill]

>
>> There is another failure in the ARM build to do with the build of
>> bytecodes_arm.s from bytecodes_arm.def. This is built in the
>> ports/hotspot directory whereas it should now be built in the
>> openjdk/hotspot/... directory.
>>
>> The quick solution is to change the definitions of ZERO_ASM_BC_DEF and
>> ZERO_ASM_BC_ASM to be openjdk/hotspot/... instead of ports/hotspot/...
>> (I have yet to test this, at home now, no ARM board).
>>
>> The longer term solution is to move the build rules for this from the
>> top level makefile to zero.make.
>>
>> Would you like me to make this change now? If I make the changes in the
>> trunk to zero.make (ie in ports/hotspot/...) can you port them across to
>> hs16?
>>
>
>I'm not sure I follow things here.  The hs16 build option doesn't do
>anything other than replace the openjdk/hotspot directory from the b17
>tarball with one from Mercurial.  Stuff is still copied from ports to
>openjdk/hotspot as it was before.

The problem is that the makefile builds bytecodes_arm.s in

ports/hotspot/src/...

instead of

openjdk/hotspot/src/...

This worked when the directories in ports/hotspot/src/... were linked to
openjdk/hotspot/src/...

However those links do not seem to be created in the hs16 build so the newly
created bytecodes_arm.s exists in ports/... but not in openjdk/...

At least that is my understanding of the problem.

I have implemented a fix for this by moving the rules to zero.make so
bytecodes_arm.s gets built whereever zero.make is.

I have 3 test builds for ARM going at the moment.

- Shark + trunk
- Zero + trunk
- Zero + hs16

The builds take about 5 hours, will let you know.

Regards,
Ed.