gcj, shared libraries, and -Bsymbolic

[Andrew Haley]

Jakub Jelinek writes:
 > On Tue, Jan 25, 2005 at 03:18:47PM +0000, Andrew Haley wrote:
 > > As far as I can see, this would only be an issue if type_info symbols
 > > are imported or exported from C++ code that had been linked into a
 > > shared library with the command "gcj".  While I suppose this is
 > > possible, it is less severe than the Java problem without -Bsymbolic.
 > 
 > Depending on what exactly Java needs, you could either use static
 > aliases (e.g. .L* symbols that would be defined in the same place
 > as the exported symbol), or on targets that support the visibility
 > attribute e.g. hidden aliases.
 > For the former, this is what e.g. cp/method.c (make_alias_for_thunk)
 > does, for the latter you'd need something similar, but with hidden
 > alias on it and defined mangling, as the symbols would be accessible
 > outside of the current .o file.

I don't think that would work.  If you have a CNI method (i.e. one
written in C++) in a Java class, that CNI method must access the local
static data of the class of which it is a member.

As I said, all this will go away once we fix the CNI implementation so
that symbol lookups use libgcj's own resolution.

Andrew.