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

[Andrew John Hughes]

2009/10/29 Edward Nevill <ed at camswl.com>:
> Hi Andrew,
>
> I tried a hs16 build on x86 and I get the same multiply defined symbol
> as I do on ARM. The config I use is
>
> ./configure --enable-zero --with-hotspot-build=hs16
>
> IE. A vanilla Zero build with no Shark or hotspot.
>
> the quick solution is to put #ifdef SHARK around the definition in
> globals_zero.hpp.
>
> However, I suspect the 'correct' solution is to move this definition to
> somewhere in the src/share/vm/shark directory.
>

As mentioned in my reply to Xerces mail, I did move it to a
Shark-specific file with a later patch.  But Gary seems to have
included it where it is now in the upstreamed Zero patch without
issue.

> 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.

> WRT mkbc.c, is the top level directory the correct place for this?
>
> Gary suggested the contrib directory at one stage?
>
> Longer term I would like to see the use of mkbc deprecated. It was a
> useful tool to allow me to rapidly prototype the ARM assembler VM.
> However, now that this has stabilised, its functionality could well be
> replaced with a set of suitable macros?
>
> Regards,
> Ed.
>
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8