Java Wrapping in Windows

Development
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.
2

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

3

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

4

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

5

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

6

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

7

What use case is not supported?

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.

9

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

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.

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.

12

Ok ! Thanks for your explanation !

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.

14

It has been fixed on master.
https://gitlab.kitware.com/vtk/vtk/merge_requests/5540

15

Thanks, I’ll do a build tomorrow.

16

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

1 Like