[vtkusers] mingw library naming - bug 10969

[David Cole]

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?

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
result.

Hopefully, the CMAKE_SHARED_LIBRARY_PREFIX can be set for VTK, and you can
get the result you're looking for.


HTH,
David


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.vtk.org/pipermail/vtkusers/attachments/20100730/cf4d9878/attachment.htm>