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.