[vtkusers] mingw library naming - bug 10969

[David Cole]

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