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

[Jim Peterson]

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
>