Mixing BC and CNI in the same executable

Stephen Kell <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.