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 <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
