Re: GCJ and C++ (calling Java from C++)

[Andrew Haley <aph at redhat dot com>]

OK, I found the problem, and it's a weird one.  

Basically, calling code linked -Bsymbolic from non-PIC code is
impossible.  An explanation is attached.

I can make your test run by compiling absolutely *everything*,
including your executable, with -fPIC.  This causes
org::eclipse::emf::examples::extlibrary::Library::class$ to be
resolved in the library where it belongs instead of being copied to
the executable.

We need to add a note to this effect the CNI manual pages.

Andrew.


http://gcc.gnu.org/ml/gcc/2001-05/msg01551.html

"Applications are typically built non-pic.  Every address is absolute,
which means that we must know the address of every object at link time
and not runtime.  Yet if symbol in question comes from a shared
library, how can this be?

"For functions, the answer is simple: the known fixed address is the
address of a PLT thunk which branches to the actual address in the
shared library.  But what about data? ...

"For every data object referenced by the main application, the linker
allocates space in the application's .bss section (sometimes referred
to as the .dynbss).  The above relocation copies the in-file contents
of the actual data in the shared library (recall that this ocurrs
before any constructors are run) to the application's .dynbss.

"Under normal conditions, the symbol resolution rules search the main
application first, and so _everyone_ uses the copy in the .dynbss,
and everyone is happy.

"But look what happens when we change the rules, as with -Bsymbolic:
the shared library searches itself first (optimized at link time in
this instance -- you'd get the same net result from ld.so if you
somehow manually added DT_SYMBOLIC to _DYNAMIC in the normal lib1),
the symbol gets resolved locally, and the application's copy is not
used.  Which then causes the application to fail."