I Downloaded the Visual Studio Express 2008 and build Vtk with Java Wrappers one more time. This was successful. the samples run and display correctly.

Sorry if my expecations from the MingW32 and MSYS compiler options in windows was too high. if they are untested and not to be used, I would suggest adding some indication from the base CMAKELIST.txt to inform the user that the results are not verified. Now that I have dll's created by both mingw and VS I can see if I can find what is probably a name mangling issue and see if I can get it resolved via vtk delivered specifications in the mingw build. I assume there might be some interest.

Thanks for all the responses. Each bit if information was useful.

Jim Peterson

Jim Peterson wrote:
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


_______________________________________________
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

Reply via email to