[CMake] mingw library naming - bug 10969
david.cole at kitware.com
Fri Jul 30 14:22:43 EDT 2010
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
Because the answer is ambiguous, there is no right answer. Therefore, we've
chosen one... which in this particular case is not yielding the correct
Hopefully, the CMAKE_SHARED_LIBRARY_PREFIX can be set for VTK, and you can
get the result you're looking for.
On Fri, Jul 30, 2010 at 2:19 PM, David Cole <david.cole at kitware.com> wrote:
> Start here:
> On Fri, Jul 30, 2010 at 1:54 PM, Jim Peterson <jimcp at cox.net> wrote:
>> 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.
>> 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
>>> 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
>>> 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,
>>> Are there any others
>>> On Fri, Jul 30, 2010 at 9:23 AM, Jim Peterson <jimcp at cox.net <mailto:
>>> jimcp at cox.net>> wrote:
>>> 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:
>>> 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
>>> 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CMake