Mixing BC and CNI in the same executable

[Stephen Kell]

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,

Stephen.