Java Wrapping in Windows

(Andrew Maclean) #1

Is anyone having trouble building Java wrapping in Windows?

I think this commit Add glTF reader and importer (Mon, 8 April2019 19:25) is the culprit: b377cf79ccbd272ce7d4d508d5f6fc53f57d5f42

I’m using VTK 8.90 Java JDK 12.0.1 and this error also occurs in JDK 11.0.1.

Also JAVA_SOURCE_VERSION and JAVA_TARGET_VERSION can only be set to a maximum of 1.9

The error seems to be related to vtkObject_Typecast.

   Creating library lib\vtkIOGeometryJava.lib and object lib\vtkIOGeometryJava.exp
vtkGLTFDocumentLoaderJava.cxx.obj : error LNK2019: unresolved external symbol vtkObject_Typecast referenced in function vtkGLTFDocumentLoader_Typecast
bin\vtkIOGeometryJava.dll : fatal error LNK1120: 1 unresolved externals

After this I get:

[5/28] Compiling Java Classes
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
[6/28] Creating vtk.jar
added manifest

and finally:

adding: vtk/vtkZLibDataCompressor.class(in = 724) (out= 384)(deflated 46%)
[7/28] Compiling Java Tests
ninja: build stopped: cannot make progress due to previous errors.
(Mathieu Westphal (Kitware)) #2

@ben.boeckel @ken-martin : what do you think of this ? look like a module dependency issue.

(Ben Boeckel) #3

Looks like VTK::IOGeometry needs to publicly depend on VTK::CommonCore now.

(Mathieu Westphal (Kitware)) #4

Why is that ? afaik vtkGLTFDocumentLoader is used only internally in the vtkGLTFImporter.

(Ben Boeckel) #5

It’s in classes, not private_classes, so it gets wrapped. It needs to be public because VTK::IOImport's vtkGLTFImporter uses it.

(Mathieu Westphal (Kitware)) #6

Make sense, that is sad that this usecase is not supported though. We will try to fix it.

(Ben Boeckel) #7

What use case is not supported?

(Mathieu Westphal (Kitware)) #8

This usecase :

vtkGLTFDocumentLoader is a class, that is not private in IOGeometry module. it is wrapped in Java as expected.

vtkGLTFImporter is a class, that is not private in IOImport, it is wrapped in Java as expected.
vtkGLTFImporter internally use vtkGLTFDocumentLoader, so it private_depends IOGeometry, yet for the Java wrapping to work, it has to depends it, which is not great for the whole module dependency system.

(Andrew Maclean) #9

One other thing. I can build in Linux with no errors. So is there some Windows oddity here?

(Ben Boeckel) #10

That use case is perfectly supported. There is a bug in the module dependency declaration. The bug is that VTK::CommonCore is not declared as a public dependency of VTK::IOGeometry. It is public because vtkGLTFDocumentLoader has it as a public dependency. Fix that and the error is gone. The new build system is much stricter and this gains us things like only adding -I flags for directories that are actually necessary (which helps ParaView not blow out command line length limits on Windows). It also means that module dependencies need to be correct.

(Ben Boeckel) #11

Linux probably finds the symbol because it is transitively loaded through other linked libraries. The Windows linker doesn’t work in the same way, so it doesn’t find the symbol since it doesn’t transitively load .lib files at link time.

(Mathieu Westphal (Kitware)) #12

Ok ! Thanks for your explanation !

(Andrew Maclean) #13

You guys are amazing, your depth of knowledge is extraordinary. I have been puzzling over this for some time and linker differences never occurred to me.

(Mathieu Westphal (Kitware)) #14

It has been fixed on master.

(Andrew Maclean) #15

Thanks, I’ll do a build tomorrow.

(Andrew Maclean) #16

Thanks to all, build is successful in Windows and Linux.

1 Like