[CMake] CMake + SWIG => Java JNI problems

[Chris Hamons]

Anybody want to take a stab at this? Maybe point me to the e-mail
address of somebody who could help. I've read what documentation
exists and poked around the source code to no avail. Google gives no
helpful answers.

Thanks,
--Chris

On Sun, Mar 21, 2010 at 11:20 PM, Chris Hamons <chris.hamons at gmail.com> wrote:
> Hello everyone,
>                I'm having trouble mixing cmake and swig to make a
> java JNI module. It looks roughly:
>
>        IF(DEFINED SWIG_JAVA)
>                FIND_PACKAGE(JNI REQUIRED)
>                include_directories(${JNI_INCLUDE_DIRS})
>                SET(CMAKE_SWIG_OUTDIR ${ROOT_DIR}/swig/generated/java/libtcod)
>                SWIG_ADD_MODULE(libtcod-java java libtcod.i)
>                SWIG_LINK_LIBRARIES(libtcod-java ${JNI_LIBRARIES} ${LIBTCOD_NAME})
>        ENDIF()
>
> With  ${LIBTCOD_NAME} being the name of the library this JNI is trying
> to wrap (libtcod-VS.dll).
>
> It builds fine, and my entire build produces:
> libtcod-VS.dll (the main library)
> libtcod-java.dll (the swig generated library)
> A bunch of .java files files I build into a .jar
>
> The problem is when I try to load it in java, I get
> UnsatisfiedLinkError errors. The error is related to symbols exported
> from libtcod-VS.dll. It seems that java JNI wants both the SWIG
> symbols and the base library symbols in the same library.
>
> What I can't seem to do is to do that. I've tried adding the cpp files
> for the library into the SWIG_ADD_MODULE list to build into
> libtcod-java.dll, however that won't link. The base library uses this
> line:
>
>        set_property(TARGET ${LIBTCOD_NAME} PROPERTY COMPILE_DEFINITIONS
> LIBTCOD_EXPORTS)
>
> to setup the headers correctly for linking. However, since the swig
> project name is abstracted via SWIG_ADD_MODULE and
> SWIG_LINK_LIBRARIES, I don't know how I can set this.
>
> Any suggestions? My {python,ruby,csharp,lua} wrappers don't have this
> problem, since they seem perfectly happy to have my swig symbols in a
> different file as the base symbols.
>
> Thanks,
> Chris Hamons
>