[CMake] mingw library naming - bug 10969

David Cole 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:
> 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 <jimcp at 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 <jimcp at cox.net <mailto:
>>> jimcp at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100730/cf4d9878/attachment.htm>

More information about the CMake mailing list