Linker errors building libgcj.so (undefined refs to hidden aliases)

[Andrew Haley]

Diego Novillo wrote:
> I am working on a patch that removes FE data from all global symbols
> and types right after we have the whole callgraph in gimple form.
>
> I'm attaching the patch for reference.  It's pretty bulky, but the
> high-level view is that we:
>
> - NULL out every symbol/type field that contains front-end data (like
> BINFO, TREE_LANG_FLAGs, etc).
> - Generate assembler names for every symbol that needs it.
> - Generate runtime types for all the EH types in ERT_CATCH and
> ERT_ALLOWED_EXCEPTION regions
> - Rewrite a bunch of lang_hooks to point to gimple variants.
>
> Clearly, it is removing something that makes us mess up some
> references.  I am getting this link failure while building libgcj.so.
>
> ./.libs/libgcj.so: undefined reference to `hidden alias for int
> java::util::zip::Inflater::getAdler()'
> ./.libs/libgcj.so: undefined reference to `hidden alias for
> JArray<java::lang::reflect::Method*>*
> java::lang::Class::getDeclaredMethods()'
>
> Has anyone seen these messages before?  I'm trying to figure out where
> should I start looking for the problem.

java::util::zip::Inflater::getAdler() is a native routine written in
C++.  In gcj we always use hidden aliases for native routines because
we want the actual address of the code, not a PLT address.  This is
partly because when we construct the vtable for a class, we don't want
vtable entries to point to PLT entries.

So, if you do

libjava $ nm --demangle java/util/zip/.libs/natInflater.o

You should see

...
0000000000000070 T hidden alias for int java::util::zip::Inflater::getAdler()
...

as well as

0000000000000070 T int java::util::zip::Inflater::getAdler()

I think something that you have done has disrupted the generation of
these hidden aliases.  See build_java_method_aliases() in cp/decl2.c.

Andrew.