vtk8.2 build/run problems on Mac

(Josh Steele) #1

I can successfully build vtk8.2 on mac. However, when I go to run the JoglConeRendering demo, I get the attached core dump. hs_err_pid93111.log (77.8 KB)

If I run things with the vtk8.1 prepackaged jar and libs that @Sebastien_Jourdain sent me, this works fine. So I’m confused why we’re getting a crash. I thought it might have something to do with our patching I’ve talked about in other posts, but clearly it doesn’t.

For completeness, here’s the portion of the (modified) build script from the Wrapping directory readme I’m using with an update cmake call - I have updated it to point to mac OS 10.14 (which I am on): (NOTE: I’ve already checked out the super build site and modified the version file to pull 8.2.0 instead of 7.1.1). If you see anything out of place, please let me know. We’re really anxious to move to 8.2 and we have to be able to build these libs ourselves since we support mac and linux. Thanks in advance!

cd vtk-java-mac-official
cd build-sb
curl -O http://jogamp.org/deployment/v2.3.2/jar/jogl-all.jar
curl -O http://jogamp.org/deployment/v2.3.2/jar/gluegen-rt.jar
curl -O http://jogamp.org/deployment/v2.3.2/jar/jogl-all-natives-macosx-universal.jar
curl -O http://jogamp.org/deployment/v2.3.2/jar/gluegen-rt-natives-macosx-universal.jar

	-DJAVA_AWT_INCLUDE_PATH:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework/Headers \
	-DJAVA_AWT_LIBRARY:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework \
	-DJAVA_INCLUDE_PATH:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework/Headers \
	-DJAVA_INCLUDE_PATH2:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework/Headers \
	-DJAVA_JVM_LIBRARY:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/JavaVM.framework \
	-DJava_IDLJ_EXECUTABLE:FILEPATH=/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/idlj \
	-DJava_JARSIGNER_EXECUTABLE:FILEPATH=/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/jarsigner \
	-DJava_JAR_EXECUTABLE:FILEPATH=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jar \
	-DJava_JAVAC_EXECUTABLE:FILEPATH=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javac \
	-DJava_JAVADOC_EXECUTABLE:FILEPATH=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javadoc \
	-DJava_JAVAH_EXECUTABLE:FILEPATH=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah \
	-DJava_JAVA_EXECUTABLE:FILEPATH=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java \
	-DJOGL_GLUE:FILEPATH=/Users/steelrj1/Desktop/vtkbuild/vtk-java-mac-official/build-sb/gluegen-rt.jar \
	-DJOGL_LIB:FILEPATH=/Users/steelrj1/Desktop/vtkbuild/vtk-java-mac-official/build-sb/jogl-all.jar \

(Sebastien Jourdain) #2

Any idea @ben.boeckel or @Dave_DeMarle ?

Is the VTK superbuild still compatible with 8.2? When did we switch from OpenGL1 to OpenGL2?

What’s the plan for the latest change that @ben.boeckel did in VTK/master in term of superbuild or packaging systsem?

(Dave DeMarle) #3

In 7.0 OpenGL2 became the default. In 8.2 OpenGL(1) was removed. The VTK superbuild project was last used for 7.1.1 as I recall so I would expect it not to work out of the box with OpenGL2 or 8.X.

We are starting to make plans for the future with the renewed NIH VTK Maintenance grant (thank you NIH!). Nothing is final yet but these are likely to include formalizing what we’ve done before for pip, debian and hopefully SDK packages (so Python and C++ first) via the new cmake infrastructure and rolling them into the regression testing and release processes to make them sustainable.

(Ben Boeckel) #4

8.2 shouldn’t have any problems on the infrastructure side. It looks like there’s a problem in GLEW though. Looking at the diff, there were lots of third party updates going into 8.2, so maybe that’s the problem here.

(Josh Steele) #5

So here’s my question then - @Sebastien_Jourdain sent me some vtk8.1 precompiled jars/libs - how were those built? That seemed to work fine. If we could replicate that with our patches, we’d be set.

I assume the super build project updates are more than just updating the version number to be 8.2.0 instead of 7.1.1?

(Ben Boeckel) #6

Moving to the common-superbuild structure rather than the old style. I suspect the install rules for the Java bits needs ironed out yet too on VTK’s side.

(Josh Steele) #7

So would pulling 8.1 and trying to build with that be a possible approach? And avoid 8.2 for now?

(Josh Steele) #8

Also as a general aside, thank you all for your responses - I am glad to see quick responses to questions on the discourse - it is very much appreciated!

(Sebastien Jourdain) #9

Yes that could be a good path forward (8.1 vs 8.2).

Also we should try to make sure we have a nice path to properly handle master. But that will require more time on our end.

(Josh Steele) #10

ok great I’ll see what I can do with 8.1. Give me a few hours for the build… :slight_smile:

1 Like
(Ben Boeckel) #11

I may have built those 8.1 binaries. It was done in a docker container most likely. I probably have its prototype around, but not the image itself. The non-Linux ones…not sure where I’d have built the macOS one; the Windows machine has since been decommissioned.

As for updating, yes, the old superbuild infrastructure is not as flexible as the new one, so updating is almost never just a string change there.

(Josh Steele) #12

So is there a suggested build process moving forward, since the old super build system is seemingly out of date?

(Ben Boeckel) #13

Basically what is happening is that the superbuild builds VTK with Java enabled and then ends up copying everything into the resulting .jar file for distribution. 8.1 probably still works, but might need some globbing fixes around where the version numbers appear. See CMake/vtk_version.cmake for the version selection. That should at least get 8.1 (and even 8.2) started to be built. At that point, the *.bundle.cmake files under Projects/* are relevant for the packaging step. If you run into issues, feel free to upload logs here and I can try to help out.

(Josh Steele) #14

Yeah I’ve been modifying that vtk_version.cmake file to force it to download the proper version from the repo for both 8.2 and now 8.1 (which I am currently building). I’ll see what happens with 8.1 and get back to you.

Thanks again for your attention to this (and all the other) post(s) I’ve been making lately. It is greatly appreciated!

(Sebastien Jourdain) #15

I have done the mac build @ben.boeckel did Windows and Linux.
It is on a mac mini next to me but currently that machine is not connected to anything.

(Josh Steele) #16

OK, I attempted to build 8.1 and get the same segfault from the original post.

@Sebastien_Jourdain if you can boot up that mini and figure out exactly how you built the version of 8.1 you sent, that would be fabulous. Thanks again.