[CMake] [vtkusers] mingw library naming - bug 10969

Jim Peterson jimcp at cox.net
Sat Jul 31 14:52:54 EDT 2010

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)

and in KitCommonJava.cmake after the ADD LIBRARY I added:

IF (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: 
    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

More information about the CMake mailing list