[vtkusers] mingw library naming - bug 10969

[David Cole]

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/d8e63131/attachment.htm>