Mixing BC and CNI in the same executable

[Bryce McKinlay]

On Sat, Jan 23, 2010 at 12:38 AM, Stephen Kell <srk31@srcf.ucam.org> wrote:
>
> I was hoping I could use BC to avoid compiling and linking a huge jar.so
> into my CNI C++ program (which only requires a few functions from the
> jar). Instead I want libgcj to load code from the jar at run time. My
> C++ code doesn't use anything in the jar directly.
>
> Should this be possible?  I initially thought not, but it's not clear
> why. (Presumably libgcj uses one ABI or other itself, or exports both;
> either of these implies that the two can be mixed somehow....)
>
> Anyway, having tried it, I'm having the following problem. I compiled
> the Java code which my CNI calls target (it happens to be the antlr
> runtime, and is packaged as another jar) with -findirect-dispatch. That
> works, but now my CNI code can't like with it, for reasons that aren't
> clear. Does an -findirect-dispatch binary still expose the right symbols
> for the "direct dispatch" ABI symbols?
>
> Here's the failure I'm seeing (huge command, sorry).
>
> gcj -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-type
> s -fPIC -g3 --classpath=./java:/home/stephen/opt/lib/java/antlr-runtime-
> 3.1.3.jar:/usr/share/java/junit-3.8.2.jar:/home/stephen/opt/lib/java/str
> ingtemplate-3.2.jar: -Wall  -L../../dwarf/libdwarfpp -L/home/stephen/opt
> /lib -L../../c++-fileno/lib -L../../libsrk31c++ -o "cake" java/cake/Clon
> eableTree.o java/cake/InternalError.o java/cake/SemanticError.o java/cak
> e/TreewalkError.o alias.o cake.o cppcatch.o derive.o dwarf.o exists.o ja
> vacatch.o link.o main.o module.o pred.o supplementary.o util.o ../../dwa
> rf/libdwarfpp/libdwarfpp.a -lsrk31c++ -Wl,--whole-archive -ldwarf -Wl,--
> no-whole-archive -ldwarfpp -lfileno -lelf -lstdc++ antlr-runtime.jar.so
>
> java/cake/CloneableTree.o: In function `cake::CloneableTree::CloneableTr
> ee(org::antlr::runtime::tree::Tree*)': /home/stephen/work/devel/cake/src
> /cake/CloneableTree.java:11: undefined reference to `org::antlr::runtime
> ::tree::CommonTree::class$'
> (snipped lots more)
>
> The funny thing is that actually, the symbols do seem to be exported...
> maybe some linker magic is stopping them from being resolved?
>
> $ objdump -t antlr-runtime.jar.so | c++filt | grep CommonTree::class
> 00083c00 l     O .rodata        00000090              org::antlr::runtime::tree::CommonTree::class$
> 000a4870 l     O .bss   00000004              .hidden org::antlr::runtime::tree::CommonTree::class$$
>
> I'm guessing the answer is "it won't work" but thought I'd ask anyway. I
> can provide a tarball on request. Thanks for reading,

It looks like the problem here is that antlr-runtime.jar.so was built
with BC, but the java code in your app binary was not. When using
BC-ABI (and specifically, -findirect-classes), the class$ symbols are
hidden.

Try building the Antlr .so with -findirect-dispatch
-fno-indirect-classes. This means that it's calls will be made with be
made with the BC ABI but class references will not - which is probably
ok most of the time.

I'd also build the java code in your app binary with
-findirect-dispatch -fno-indirect-classes.

Bryce