VTK 9 + Java on Mac

I’ve started a local VS2017 Release build to see if anything turns up. @Marco, were you doing a parallel build, e.g. /m:2 or /m:4?

Hello David,

thank you for checking.

Please notice that I obtain the exception in vtkWrapHierarchy only when using the Ninja build system under Windows (I was testing with a Debug build).

On the other side, if I choose VS 2017, build works fine, but .java files are NOT compiled into .class files, and vtk.jar archive is NOT produced. With VS 2017, I used “standard” CMake settings for generating project files (including Java wrapping and JOGL, x64 architecture), so I am not sure if this translates into a “parallel build” or not. But again, on VS I don’t have that crash, in this case the issue is with the missing generation of vtk.jar.

Tomorrow I will be able to do any additional test which may be useful to troubleshoot the problem.

I am looking forward to hearing from you.

Thanks and best regards,

Marco

For the VS 2017 build, I also saw no .class files and no .jar. So those are definitely missing for this generator. And l also saw no difference when building vtkjava specifically.

Regarding the parallel build, I meant the visual studio option for accelerating the build with multiple cores. I’m not sure how it is set in the GUI, since I always do visual studio builds on the command line and use the “-m” option:

msbuild VTK.sln /m:4 /property:Configuration=Release

The reason I was curious is that, if the dependencies chain is incorrectly generated for Visual Studio, then during a parallel build it is possible that vtkWrapHierarchy might use an input file that is only partly generated by a previous step. But I didn’t see a crash when using “-m:4” for my Visual Studio build, and as you said, you saw it specifically for a Ninja build.

In any case, if you ever see the vtkWrapHierarchy crash occur in the future, please let me know.

Thanks David for confirming.
I would really appreciate if someone could have a look at why .class and .jar files are not being generated when building VTK 9 when using VS 2017 as the output generator for CMake.

This afternoon I will try to analyze the issue with vtkWrapHierarchy that I am getting during the Windows build when using Ninja as the build system.

Also the warning that I am getting on the compilation of (apparently) every .cxx file with Ninja (warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc) sounds a bit suspicious to me, I am not sure it can be safely ignored. Any comment on this?

I am not getting this kind of warning when compiling through VS 2017. However, in this case vtk.jar is not generated.

So, overall, at the moment there is no working build combination for VTK 9 (+ Java) under Windows for me.

In the meanwhile, I have made progresses under macOS (using Ninja), and I have the JoglConeRendering sample working under that platform, at least in GLCanvas mode. See (https://gitlab.kitware.com/vtk/vtk/-/issues/17831) for details.

Now, I would very much like to obtain at least the same result under Windows.

Thanks in advance for your comments.

Best regards,

Marco Sambin

My guess is that the Java language support for add_library just doesn’t work there. Though why CMake doesn’t complain and instead just silently ignores the call instead is odd. @brad.king Thoughts?

Are you manually setting flags related to this? I’ve not seen this. I see pugixml suppressing the warning, but that’s about it.

Hi Ben,

thanks for your feedback.

VS 2017 build of VTK 8.2.0 was working 100% fine, .class files were produced correctly, and vtk.jar generated without any problem. Were makefiles different for VTK 8.2.0 as far as building of Java class files is concerned?

Regarding the Ninja build under Windows, and the compilation warnings that I reported in my previous message, today I will make a brand-new attempt starting from a “clean” situation, and I will report back.
I did not set any custom flag manually in my previous attempt.

By the way, I’ve taken a look at the compilation options which are set on my VS 2017 project, as produced by CMake’s output when choosing VS 2017 as the generator, and the “/EHsc” option (see warning in my previous post) is indeed present in the compiler command line. So, I am not sure why it would not be present in case of using Ninja as the generator.

A preliminary question: is Ninja the “standard / usual” build system you use also under Windows for building VTK (including Java)? Or should I prefer VS 2017 as the generator?

Thanks in advance for your feedback.
Best regards,

Marco Sambin

Yes, VTK manually constructed the javac lines to make these and same with the .jar. Now we expect CMake to do that stuff. This also lets us make a proper target that can be used outside of VTK.

Ninja is certainly the most well-tested. VS should work for everything, but it seems that VS/Java support is lacking, so if you need Java, it sounds like VS is not yet supported.

Regarding the compiler flags, I see identical default flags regardless of whether the Ninja generator or VS2017 generator is used:

CMAKE_CXX_FLAGS:STRING=/DWIN32 /D_WINDOWS /W3 /GR /EHsc

Hi Ben,

and thanks a lot for your feedback, which is really appreciated.

I beg your pardon for the slightly off-topic question, but can you clarify where I choose the build architecture (whether x86 or x64) in CMake when using “Ninja (Multi-Config)” as the generator?

When using VS 2017 as the generator, I used to select the build architecture in the same screen where I select the generator, but I see no such option with Ninja:

image

Should I manually set all compiler and linker flags at a later stage in order to target x86 or x64 platform, or there is an easier alternative?

Thanks a lot for your feedback.
Best regards,

Marco Sambin

For this case, it depends on the VS developer prompt you started CMake from.

You can start a specific VS Developer Command Prompt from the Start menu, or alternatively you can run CMD.EXE and set the necessary environment variables, e.g.:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64

Then cmake and ninja must be run from this same command prompt. For the sake of convenience, I use the cmake (v3.12) that Microsoft ships with VS2017.

Just to add some info. I’ve been previously compiling VTK 9 RC 1 and 2 on Linux, and all went well. With 9.0 release I encountered two problems.

First, in addition to the usual Java_JAVAC_EXECUTABLE I needed also to set CMAKE_Java_COMPILER to point to javac. That was never the case before.

After that, VTK did build almost to completion: I didn’t get any JAR file, although the class files were compiled correctly. The problem seems to be the last stage of creating the JAR file - the jar program in the final “linking” command is empty. If you look at build/Wrapping/Java/CMakeFiles/vtkjava.dir/link.txt:

"" -cf ../../lib/java/vtk.jar -C CMakeFiles/vtkjava.dir .

If you substitute "" with jar after CMake is done with generation, then all works.

Yesterday I tried to compile on Windows. The standard Visual Studio generator failed to compile classes. The Ninja generator compiled the classes correctly, but - just as on Linux - failed in the final step of creating the JAR file. In the rules.ninja file I found the following:

rule Java_STATIC_LIBRARY_LINKER__vtkjava
  command = cmd.exe /C "$PRE_LINK && "" -cf $TARGET_FILE -C $OBJECT_DIR . && $POST_BUILD"

which looks exactly like the link.txt file on Linux. Now, I substituted "" with C:\PROGRA~1\Java\JDK18~1.0_2\bin\jar.exe in the above rule. After that VTK built correctly.

Thanks for digging in. It seems you also need Java_JAR_EXECUTABLE then.

Oh, but I do have it. As before, when the code compiled fine. The problem is that in VTK 9.0 it is not used - apparently. Maybe something else is? As I wrote before, I had to suddenly set CMAKE_Java_COMPILER, but I was informed about this by cmake. Maybe I need something similar for jar?

Just as a clarification. I previously compiled VTK 9rc2 on linux, and had no such problems. So I guess it is a very recent change.

Yes, there were lots of last minute Java changes due to folks coming in and saying it wasn’t working for them. I am able to build on Linux and was also able to get macOS without issue when I was testing it.

Yes, we now use CMake’s Java support (as I’ve said multiple times). We used to make custom commands for compiling each .java file and then creating the jar ourselves with add_custom_command. Now we just tell CMake to make the jar file. If something goes wrong after that, it is a CMake problem, not a VTK problem. I suspect that VS doesn’t support Java, but the rest seems like CMake should be making noise that it doesn’t have the tools to actually make the jar and erroring.

right. So looking at build/CMakeFiles/3.13.4/CMakeJavaCompiler.cmake, maybe what I need to do is set CMAKE_Java_ARCHIVE at configure. Strange that CMake complains about not seeing javac, but is silent about jar. I will try.

Yay! I did not build yet, but looking at the link.txt file I mentioned, things look very good:

jdk1.8.0_77/bin/jar -cf ../../lib/java/vtk.jar -C CMakeFiles/vtkjava.dir .

So yes, CMAKE_Java_ARCHIVE has to be set in order to compile java bindings in VTK9.

Thanks. Let’s get a laundry list of problems prepped for a CMake issue.

  • silent about java support in VS (instead of erroring with a useful message or actually working)
  • no error if the java “linker” is not set (and used?)

Hello.

I’ve just made a “clean” Windows Ninja Multi-Config build of VTK 9 (GIT master) + JOGL (latest RC), and finally I had no issues at all. Java was properly detected, DLLs were produced correctly, .class files and vtk.jar archive were produced correctly.

When using Ninja, the key seems to be to have the environment variables (for instance for OpenSSL) appropriately set BEFORE starting CMake and the first “configure” attempt. Once I had this, everything worked smoothly in my case, and I had not issues in configure, generate and build phases.

However, there seem to be still issues with VTK+JOGL functioning, and we are treating this here:

https://gitlab.kitware.com/vtk/vtk/-/issues/17831#

Strangely enough, the JoglConeRendering example seems to work:

  • Correctly in GLJPanel mode, incorrectly in GLCanvas mode on Windows
  • Correctly in GLCanvas mode, incorrectly in GLJPanel mode on macOS

I’ve made an apitrace on Windows and we are proceeding in the analysis of the issue.

Regards,

Marco