Start here: http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_SHARED_LIBRARY_PREFIX
On Fri, Jul 30, 2010 at 1:54 PM, Jim Peterson <ji...@cox.net> wrote: > David, > IMHOP, the naming of the java DLL is dictated by the java behavior on the > platform, not the compiler in use. Static libraries can be named with the > lib prefix according to the compiler requirements, but runtime libraries (on > windows DLLs) need to be named according to the runtime users requirements. > also, it appears that the internal logic within the VTK Java wrappers > expects to load the shared implementation libraries without the lib prefix. > > I will see if I can get the visual studio compile put together, but my > strong suspicion is the output from the VS shared libraries and wrappers is > a suite of DLL's without the lib prefix, and therefore compatible with the > Java runtime expectations. > > meanwhile, can you let me know which modules establish target library names > used in the link.txt and build.make outputs? or some point of reference to > get familiar with the cmake structure that results in the generation of the > sets of make files? I will see if I can get the files generated with my > impression of correct DLL names. > Thanks, > Jim > > David Cole wrote: > >> I could be wrong... I'm not a huge mingw user, but I think this is the >> expected library naming for a mingw build. >> >> If so, then the VTK java wrapping code is just not going to work on mingw >> as it stands now. I suspect there are few, if any, users of java wrappers >> using a mingw build of VTK. If there are, they must be patching it >> somehow... >> >> The java wrappers in VTK are the least used (of python, tcl and java), but >> I do know that they work with Visual Studio builds of VTK. Maybe you could >> try with a Visual Studio Express build of java-wrapped VTK? >> >> Or perhaps other VTK-on-mingw users could chime in here with their own >> advice. >> >> Either way, I do not think 10969 is a CMake bug. I'm going to move it to >> the VTK project. If I am wrong, and somebody else convinces me otherwise, >> I'll be happy to move it back later. >> >> >> Hope this helps, >> David >> >> >> Are there any others >> On Fri, Jul 30, 2010 at 9:23 AM, Jim Peterson <ji...@cox.net <mailto: >> ji...@cox.net>> wrote: >> >> David, >> >> I am new to this list and vtk, One point I have noticed is that I >> have been unable to correctly generate the Java wrappers for VTK >> using cmake and cmake-gui for the windows hosted jvm. I have >> opened a bug tracker incident >> http://public.kitware.com/Bug/view.php?id=10969 which is currently >> unassigned. The nature of the problem is the java test programs >> that use the java statement: >> System.loadLibrary("vtkCommonJava"); >> fails on my Windows machine with unable to load vtkCommonJava.dll. >> the superficial reason for this appears to be that the generated >> make file is creating a dll named libvtkCommonJava.dll. The >> windows system specific behavior when processing the loadLibrary >> command only appends dll, it does not prepend lib to the name >> specified. >> This naming behavior appears to be true for all shared libraries, >> so simply renaming libvtkCommonJava.dll to vtkCommonJava.dll >> results in a failure to load vtkCommon.dll during the vtk Java dll >> initialization. >> >> I am not completely versed in the specifications for cmake, if >> there is some option that can effect this behavior and correct the >> shared library naming rules I would be happy to use it >> >> Thanks for your patience with me as I learn this tool, >> Jim Peterson >> >> >> >
_______________________________________________ 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
