Andre,
thanks, I think I finally found a potentially productive path for a
resolution to this issue. The vtk CMAKE directory has two cmake "macros"
(KitCommonBlock.cmake and KitCommonJavaBlock.cmake) in
KitCommonBlock.cmake the ADD_LIBRARY I added:
IF (WIN32)
SET_TARGET_PROPERTIES (vtk${KIT} PROPERTIES PREFIX "" )
ENDIF (WIN32)
and in KitCommonJava.cmake after the ADD LIBRARY I added:
IF (WIN32)
SET_TARGET_PROPERTIES (vtk${KIT}Java PROPERTIES PREFIX "" )
ENDIF (WIN32)
This has the outputs created so that the delivered java samples at least
get past the load of the JNI libraries.
What I am seeing now is a failure in VTKObject at the line:
this.vtkId = this.VTKInit();
in the VTKObject constructor.
The trace back when running the CONE.JAVA example is:
vtk libraries loaded
Exception in thread "main" java.lang.UnsatisfiedLinkError:
vtk.vtkConeSource.VTKInit()J
at vtk.vtkConeSource.VTKInit(Native Method)
at vtk.vtkObject.<init>(vtkObject.java:96)
at vtk.vtkAlgorithm.<init>(vtkAlgorithm.java:765)
at vtk.vtkPolyDataAlgorithm.<init>(vtkPolyDataAlgorithm.java:163)
at vtk.vtkConeSource.<init>(vtkConeSource.java:114)
at Cone.main(Cone.java:35)
Based on this revelation, I am going to say CMAKE does not have a bug as
originally reported in 10969. but there still may be some interface
requirement to resolve for use of the java wrappers in a Windows JVM.
Does anyone know if the vtkObject.cxx is supposed to implement a VTKInit
function? if not, where exactly is that supposed to be from?
Thanks for the patience and information you folks have provided.
Jim Peterson
André Prins wrote:
Hi All,
Allow me to chime in a little on the use of Vtk libs with MinGW. I
also reported a python-wrapping and installation issue a few days ago
as a response to the mail from Jim.
What is the primary user of a mingw compiler system trying to achieve?
Somebody trying to build unix-y stuff for Windows?
Or somebody trying to build unix-y stuff to still be unix-y in an MSYS shell
environment?
The most important reason for me is that I can test my source-code for
compatibility with the Gcc compiler, without having to setup a Linux
machine or a full cygwin environment. Second, I used gcc a lot (in
Unix/Linux), but am stuck with a windows-environment nowadays. It is
simply faster for me to set up a small test-application with a
makefile (or CMakeLists.txt) then to open up a new visual studio
project. Starting visual studio is slow on an Asus EEE Netbook.
Personally, I would say: get rid of the lib-prefix in MinGW...
1) It implies a consistent dll and pyd name on windows, which is good.
2) It probably solves the install errors with MinGW and python-wrapping.
This is something which can be done with CMake and is what I do when I
want my own vtk-library wrapped with python. E.g., I have a "Readers"
library, which does the following in CMake:
add_library( ReadersPython SHARED ${ReadersPython_SRCS} )
# Ensure the lib-prefix is gone and the library ends with .pyd
set_target_properties( ReadersPython PROPERTIES PREFIX "" )
set_target_properties( ReadersPython PROPERTIES SUFFIX ".pyd" )
I have not encountered any problems with this approach. I guess this
is similar to setting a "system-wide" CMAKE_SHARED_LIBRARY_PREFIX?
Regards,
Andre
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
