search

visit-dav / visit

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data
https://visit.llnl.gov
BSD 3-Clause "New" or "Revised" License
400 stars 110 forks source link

Cannot generate any Expression with VisIt 3.1.1? #12250

Closed markcmiller86 closed 2 years ago

markcmiller86 commented 3 years ago

We're trying to combine visit-users email list with GitHub issues. When replying on visit-users, please reply only to emails with a Subject line that includes [visit-dav/live-customer-response].

Hello,

I haven't used Expressions for quite some time, but today I tried to use them and realized that I cannot get even the simplest one to work. Not sure what could be wrong.

The VisIt version is 3.1.1.

I start visit with: visit -debug 5

and load the noise.silo sample datafile.

In the Expressions window I create a new Scalar mesh variable, just a simple abs(airVf), but when I try to plot it (PseudoColor) I get a message like:

,---- The compute engine [...] has exited abnormally.
Shortly thereafter, the following occured...
The Pseudocolor plot of "unnamed1" for the file
"/home/angelv/spack/opt/spack/linux-arch-skylake_avx512/gcc-8.3.0/visit-3.1.1-43iwx2qkxjgwy5fd4egl77d6zuwzchus/data/noise.silo"
could not be generated by the compute engine on host "localhost".

`----

Any idea what could be going on? (I attach the A.engine_ser.5.vlog)

Thanks,

A.engine_ser.5.vlog.gz

markcmiller86 commented 3 years ago

Hmm....The error message you report along with the engine log you provided suggests this is a version of VisIt built using Spack. Is that correct? Next, it looks like you are reading data from the test file noise.silo, correct? The engine is SEGV'ing and just before it I see a line in the log file...

Memory after first execution was: size = 2601881600, rss = 98324480

Which suggests (I think), ~2.4 Gigabytes of memory was in use. That seems way high for anything in this test file or the simple abs() expression function.

Does a normal PC plot of airVf work?

angel-devicente commented 3 years ago

Hi,

yes, VisIt was built with Spack.

A normal Pseudocolor plot of airVf works without issues.

Actually, a Volume plot of the expression "abs(airVf)" works without issues, so it looks like the problem is not with the expression itself, but with some of the plots...

angel-devicente commented 3 years ago

I just installed version 3.0.1 (the same way, with Spack, and it uses exactly the same compiler/packages for everything, so only VisIt itself is different), and no issues with the expressions / Pseudocolors I tried.

markcmiller86 commented 3 years ago

@angel-devicente thanks for taking the time to investigate that 🥇 . Very useful information. That said, I am still suspect of the Spack build because we test a slew of expressions in our nightly testing and haven't seen anything like this issue. Out of curiosity, have you used build_visit in the past to build VisIt and if so, can you elaborate on why you might now be preferring Spack over build_visit.

Reason for all of this is that we've put a ton of effort into making build_visit work but less into Spack yet.

markcmiller86-visit commented 3 years ago

Hello,

"Mark C. Miller via visit-users" visit-users@elist.ornl.gov writes:

That said, I am still suspect of the Spack build because we test a slew of expressions in our nightly testing and haven't seen anything like this issue.

I've been using many different versions of VisIt, and this is also the first time I see anything like this. Maybe you are right, and it is something with the Spack build, but given that 3.0.1 was built in the same way and in the same workstation/compiler/packages, I don't understand what could be causing it for the 3.1.1.

Out of curiosity, have you used build_visit in the past to build VisIt and if so, can you elaborate on why you might now be preferring Spack over build_visit.

Yes, until recently all my VisIt installations were either with the binary files (in case I didn't need anything special), or (mostly) by using build_visit. But in my current workstations, where I have ArchLinux installed, the build_visit script was giving a number of problems (I have them documented for VisIt 2.13.2 and 3.0).

If I try now to compile version 3.1.1, I don't get very far with the build_visit script:

,---- | angelv@sieladon:~/temp$ ./build_visit3_1_1 | Processing bsd license. | [build_visit invocation arguments] | g++ version 10.2.0 | Need g++ version >= 4.8 `----

In this machine I also have gcc@8.3.0, so I try with that instead:

,---- | angelv@sieladon:~/temp$ ./build_visit3_1_1 | Processing bsd license. | [build_visit invocation arguments] | g++ version 8.3.0 | Could not obtain a 3.2 context with system GL. | You may want to add --mesagl to the command line. | To disable this check use --skip-opengl-context-check `----

So, I try with --mesagl (although the idea of software rendering in a box with a nice GPU card is not very appealing, but just to try), and I have trouble compiling Qt (I attach the compressed log file)

,---- | angelv@sieladon:~/temp$ ./build_visit3_1_1 --mesagl --llvm | [...] | Done building GLU | Building Qt (~60 minutes) | Unzipping/Untarring qt-everywhere-src-5.10.1.tar.xz . . . | Patching qt . . . | Patching qt 5.10.1 for Linux and Mesa-as-GL | Patching qt 5.10.1 for Blueos | Configuring Qt5: CFLAGS= -m64 -fPIC -O2 CXXFLAGS= -m64 -fPIC -O2 | ./configure -prefix | /home/angelv/temp/third_party/qt/5.10.1/linux-x86_64_gcc-8.3 -platform | linux-g++-64 -make libs -make tools -no-separate-debug-info -no-dbus | -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc | -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -no-sql-tds -no-libjpeg | -opensource -confirm-license -skip 3d -skip canvas3d -skip charts -skip | connectivity -skip datavis3d -skip doc -skip gamepad -skip | graphicaleffects -skip location -skip multimedia -skip networkauth -skip | purchasing -skip quickcontrols -skip quickcontrols2 -skip remoteobjects | -skip scxml -skip sensors -skip serialport -skip speech -skip wayland | -nomake examples -nomake tests -no-qml-debug -qt-zlib -qt-libpng -qt-xcb | -qt-xkbcommon | Building Qt5 . . . (~60 minutes) | Qt5 build failed. Giving up | Unable to build or install Qt. Bailing out. | Error in build process. See build_visit3_1_1_log for more | information. If the error is unclear, please include | build_visit3_1_1_log in a message to the visit-users@ornl.gov list. | You will probably need to compress the build_visit3_1_1_log using a | program like gzip so it will fit within the size limits for email | attachments. `----

So I try in a Ubuntu 19.10 Virtual Machine, and I install VisIt 3.1.1 from binaries. As expected, no problem with generating a Pseudocolor plot out of expression "abs(airVf)".

AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information: https://www.iac.es/en/disclaimer

brugger1 commented 3 years ago

The latest build_visit3_1_3 will probably build VisIt on your newest virtual machines. I've tested it with ubuntu20 and fedora core 31.

angel-devicente commented 3 years ago

Eric Brugger notifications@github.com writes:

The latest build_visit3_1_3 will probably build VisIt on your newest virtual machines. I've tested it with ubuntu20 and fedora core 31.

I tried with a fresh Ubuntu 20.04 virtual machine, but it looks like the build_visit script has some trouble not finding the right makefile in order to compile cmake (I attach the log file). I tried the script for 3_1_1, since that's the one it started this exchange.

AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information: https://www.iac.es/en/disclaimer

markcmiller86 commented 3 years ago

FYI...am trying spack install visit but on an OSX system...

miller86% time spack install visit
==> Warning: apple-clang@11.0.0 cannot build optimized binaries for "skylake". Using best target possible: "x86_64"
==> Error: An unsatisfiable version constraint has been detected for spec:

    python@2.7.18%apple-clang@11.0.0+bz2+ctypes+dbm~debug+libxml2+lzma~nis~optimizations+pic+pyexpat+pythoncmd+readline+shared+sqlite3+ssl~tix~tkinter~ucs4+uuid+zlib arch=darwin-mojave-x86_64
        ^bzip2@1.0.8%apple-clang@11.0.0+shared arch=darwin-mojave-x86_64
            ^diffutils@3.7%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^libiconv@1.16%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^expat@2.2.9%apple-clang@11.0.0~libbsd arch=darwin-mojave-x86_64
        ^gdbm@1.18.1%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^readline@8.0%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^ncurses@6.2%apple-clang@11.0.0~symlinks+termlib arch=darwin-mojave-x86_64
                    ^pkgconf@1.7.3%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^gettext@0.21%apple-clang@11.0.0+bzip2+curses+git~libunistring+libxml2+tar+xz arch=darwin-mojave-x86_64
            ^libxml2@2.9.10%apple-clang@11.0.0~python arch=darwin-mojave-x86_64
                ^xz@5.2.5%apple-clang@11.0.0~pic arch=darwin-mojave-x86_64
                ^zlib@1.2.11%apple-clang@11.0.0+optimize+pic+shared arch=darwin-mojave-x86_64
            ^tar
        ^libffi@3.3%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^openssl@1.1.1g%apple-clang@11.0.0+systemcerts arch=darwin-mojave-x86_64
            ^perl@5.30.3%apple-clang@11.0.0+cpanm+shared+threads arch=darwin-mojave-x86_64
                ^berkeley-db@18.1.40%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^sqlite@3.33.0%apple-clang@11.0.0+column_metadata+fts~functions~rtree arch=darwin-mojave-x86_64

while trying to concretize the partial spec:

    py-setuptools@50.1.0%apple-clang@11.0.0 arch=darwin-mojave-x86_64

py-setuptools requires python version 3.5:, but spec asked for 2.7.18
cyrush commented 3 years ago

@markcmiller86 check out the embedded comments in the VisIt spack package for how to setup the deps. You have to apply constraints to get the right set of deps wired up.

markcmiller86 commented 3 years ago

I have a few questions for myself about the above output from Spack's error message. These are really questions about Spack from the perspective of a newbie (which I certainly am not) trying to use it.

cyrush commented 3 years ago

Visit still reqs Python 2.7.

The chain of dependencies is hard to untangle -- when I last built and worked out the issues for spack -- the problem was actually a build system dependency (a dep for a build system for one of the chain of things) that conflicted needing Python 3.

markcmiller86 commented 3 years ago

check out the embedded comments in the VisIt spack package for how to setup the deps

I didn't know to go look there. Thanks for mentioning! I see those commands now and am trying. That said, I think we should move those few lines from the comment block in packages.py to the actual python doc string so that spack info visit will at least produce that little bit of additional (and also critical) info.

cyrush commented 3 years ago

Lol, I tried to have those there :-) But the formatting looked bad and folks even pushed back on the comments to begin with, so it was a little bit of an up-hill battle.

markcmiller86-visit commented 3 years ago

"Mark C. Miller via visit-users" visit-users@elist.ornl.gov writes:

FYI...am trying spack install visit but on an OSX system...

miller86% time spack install visit ==> Warning: apple-clang@11.0.0 cannot build optimized binaries for "skylake". Using best target possible: "x86_64" ==> Error: An unsatisfiable version constraint has been detected for spec:

In my case (ArchLinux), to get it installed with Spack I had to do:

spack install visit %gcc@8.3.0 ^python+shared ^glib@2.56.3 ^py-setuptools@44.1.0

But Qt does not compile cleanly. I have to do the following changes to the QT sources:

In /tmp/angelv/spack-stage/spack-stage-qt-5.14.2-[...] add: #include in qtimageformats/src/plugins/imageformats/jp2/qjp2handler.cpp add: #include in qtlocation/src/3rdparty/mapbox-gl-native/platform/default/bidi.cpp add: #include in /qtlocation/src/3rdparty/mapbox-gl-native/src/mbgl/util/convert.cpp

AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information: https://www.iac.es/en/disclaimer

markcmiller86 commented 3 years ago

Ok, my attempt to install VisIt via spack on osx failed after 5.5 hours of building. It installed these packages...

==> 72 installed packages
-- darwin-mojave-x86_64 / apple-clang@11.0.0 --------------------
autoconf@2.69            freetype@2.10.1   libedit@3.1-20191231  libxml2@2.9.10  pcre2@10.35             readline@8.0
automake@1.16.2          gdbm@1.18.1       libffi@3.3            llvm@10.0.1     perl@5.30.3             silo@4.10.2
berkeley-db@18.1.40      gettext@0.21      libice@1.0.9          lz4@1.9.2       perl-data-dumper@2.173  sqlite@3.33.0
bison@3.6.4              glew@2.1.0        libiconv@1.16         m4@1.4.18       pixman@0.40.0           swig@4.0.2
bzip2@1.0.8              glib@2.56.3       libjpeg-turbo@2.0.4   mesa@18.3.6     pkgconf@1.7.3           tar@1.32
cairo@1.16.0             harfbuzz@2.6.8    libmng@2.0.3          nasm@2.15.05    py-mako@1.0.4           texinfo@6.5
cmake@3.18.2             hdf5@1.10.7       libpng@1.6.37         ncurses@6.2     py-markupsafe@1.1.1     util-macros@1.19.1
diffutils@3.7            help2man@1.47.11  libsigsegv@2.12       netcdf-c@4.7.4  py-mpi4py@3.0.3         xproto@7.0.31
double-conversion@2.0.1  hwloc@1.11.11     libsm@1.2.3           netcdf-cxx@4.2  py-setuptools@44.1.0    xtrans@1.3.5
expat@2.2.9              icu4c@67.1        libtiff@4.1.0         openmpi@3.1.6   python@2.7.18           xz@5.2.5
findutils@4.6.0          jsoncpp@1.9.2     libtool@2.4.6         openssl@1.1.1g  qt@5.14.2               z3@4.8.7
flex@2.6.4               lcms@2.9          libuuid@1.0.3         pcre@8.44       qwt@6.1.4               zlib@1.2.11

The package that failed to build was VTK, the first few lines of output were...

==> Installing vtk
==> No binary for vtk found: installing from source
==> Warning: microarchitecture specific optimizations are not supported yet on mixed compiler toolchains [check apple-clang@11.0.0 for further details]
==> Fetching https://spack-llnl-mirror.s3-us-west-2.amazonaws.com/_source-cache/archive/09/0995fb36857dd76ccfb8bb07350c214d9f9099e80b1e66b4a8909311f24ff0db.tar.gz
######################################################################## 100.0%
==> vtk: Executing phase: 'cmake'
==> vtk: Executing phase: 'build'
==> Error: ProcessError: Command exited with status 2:
    'make' '-j8'

14 errors found in build log:
     39843    In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15
              .sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:89:
     39844    In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15
              .sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:15:
     39845    In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15
              .sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:23:
     39846    In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15
              .sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
     39847    In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15
              .sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:208:
     39848    In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15
              .sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/HFSVolumes.h:25:
  >> 39849    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/hfs/h
              fs_format.h:794:2: error: unknown type name 'uuid_string_t'; did you mean 'io_string_t'?
     39850            uuid_string_t   ext_jnl_uuid;
     39851            ^
     39852    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/devic
              e/device_types.h:89:33: note: 'io_string_t' declared here
     39853    typedef char                    io_string_t[512];
     39854                                    ^
     39855    In file included from /var/folders/nx/mtgf501d3573jd6cmgv9lnzr0003jr/T/miller86/spack-stage/spack-stage-vtk-8.1.2-eai

A subsequent attempt with slightly different spec also failed.

markcmiller86 commented 3 years ago

The VTK build looks like it is resolving a number of dependencies to stuff inside of Xcode. A search of the CMakeCache.txt file reveals...

% grep -i xcode CMakeCache.txt | tr ';' '\n' | sort | uniq | grep -i xcode
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libdl.tbd
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libm.tbd
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libm.tbd][/Users/miller86/visit/spack/spack/opt/spack/darwin-mojave-x86_64/apple-clang-11.0.0/hdf5-1.10.7-47vdov2bmqdoy6kt67qnyu7od6kvycuu/lib/libhdf5_hl.dylib][cfound components: C HL ][v1.10.7()]
CMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
FIND_PACKAGE_MESSAGE_DETAILS_OpenGL:INTERNAL=[/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework][/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework][c ][v()]
HDF5_C_LIBRARY_dl:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libdl.tbd
HDF5_C_LIBRARY_m:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libm.tbd
LIBPROJ_M_LIB:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libm.tbd
OPENGL_INCLUDE_DIR:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework
OPENGL_gl_LIBRARY:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework
OPENGL_glu_LIBRARY:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework
PYTHON_UTIL_LIBRARY:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/lib/libutil.tbd

This troubles me for two reasons. First, I don't ever use Xcode, for any project I develop on OSX. I use straight shell. Second, because this is a Spack build, isn't VTK supposed to be finding all these dependencies in Spack?

mclarsen commented 3 years ago

I think this is the danger of spack: you have no idea what the packages are doing unless you dig in. For example, VisIt could have simply ignored everything in spack and simply called build_visit. In VisIt's case a huge amount of effort has gone into the build_visit script. Duplicating this inside spack is cost prohibitive, and I suspect that there is a similar investment inside vtk's cmake (or maybe its just spack is not connected to the cmake variables).

mclarsen commented 3 years ago

what happens when you spack spec vtk?

markcmiller86 commented 3 years ago

In VisIt's case a huge amount of effort has gone into the build_visit script

Yes, and I don't think it would download or require one to have in hand the majority of those packages listed above, or would run for 5.5 hours consuming 99% of my CPU and in the end would build the majority of VisIt functionality including all the database third party libs. That'll be my answer next time someone asks me why maintaining build_visit is still a good idea 😉

markcmiller86 commented 3 years ago

If I spack spec vtk I get a short spec and an error message about an unsatisfied external. However...

% spack spec vtk ^hwloc@:1.999
Input spec
--------------------------------
vtk
    ^hwloc@:1.999

Concretized
--------------------------------
==> Warning: apple-clang@11.0.0 cannot build optimized binaries for "skylake". Using best target possible: "x86_64"
vtk@9.0.0%apple-clang@11.0.0~ffmpeg+mpi+opengl2~osmesa~python~qt~xdmf build_type=RelWithDebInfo arch=darwin-mojave-x86_64
    ^cmake@3.18.2%apple-clang@11.0.0~doc+ncurses+openssl+ownlibs~qt arch=darwin-mojave-x86_64
        ^ncurses@6.2%apple-clang@11.0.0~symlinks+termlib arch=darwin-mojave-x86_64
            ^pkgconf@1.7.3%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^openssl@1.1.1g%apple-clang@11.0.0+systemcerts arch=darwin-mojave-x86_64
            ^perl@5.30.3%apple-clang@11.0.0+cpanm+shared+threads arch=darwin-mojave-x86_64
                ^berkeley-db@18.1.40%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^gdbm@1.18.1%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                    ^readline@8.0%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^zlib@1.2.11%apple-clang@11.0.0+optimize+pic+shared arch=darwin-mojave-x86_64
    ^double-conversion@2.0.1%apple-clang@11.0.0 build_type=RelWithDebInfo arch=darwin-mojave-x86_64
    ^eigen@3.3.7%apple-clang@11.0.0 build_type=RelWithDebInfo arch=darwin-mojave-x86_64
    ^expat@2.2.9%apple-clang@11.0.0~libbsd arch=darwin-mojave-x86_64
    ^freetype@2.10.1%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^bzip2@1.0.8%apple-clang@11.0.0+shared arch=darwin-mojave-x86_64
            ^diffutils@3.7%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^libiconv@1.16%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^libpng@1.6.37%apple-clang@11.0.0 arch=darwin-mojave-x86_64
    ^glew@2.1.0%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^libice@1.0.9%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^util-macros@1.19.1%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^xproto@7.0.31%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^xtrans@1.3.5%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^libsm@1.2.3%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^libuuid@1.0.3%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^mesa@18.3.6%apple-clang@11.0.0~glx+llvm+opengl~opengles+osmesa patches=55a5611ca9fcbe8324c4d68a07b338134954ff12c5b122dc78ff376f012a1414 swr=none arch=darwin-mojave-x86_64
            ^autoconf@2.69%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^m4@1.4.18%apple-clang@11.0.0+sigsegv patches=3877ab548f88597ab2327a2230ee048d2d07ace1062efe81fc92e91b7f39cd00,c0a408fbffb7255fcc75e26bd8edab116fc81d216bfd18b473668b7739a4158e,fc9b61654a3ba1a8d6cd78ce087e7c96366c290bc8d2c299f09828d793b853c8 arch=darwin-mojave-x86_64
                    ^libsigsegv@2.12%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^automake@1.16.2%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^bison@3.6.4%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^help2man@1.47.11%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                    ^gettext@0.21%apple-clang@11.0.0+bzip2+curses+git~libunistring+libxml2+tar+xz arch=darwin-mojave-x86_64
                        ^libxml2@2.9.10%apple-clang@11.0.0~python arch=darwin-mojave-x86_64
                            ^xz@5.2.5%apple-clang@11.0.0~pic arch=darwin-mojave-x86_64
                        ^tar@1.32%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^flex@2.6.4%apple-clang@11.0.0+lex patches=09c22e5c6fef327d3e48eb23f0d610dcd3a35ab9207f12e0f875701c677978d3 arch=darwin-mojave-x86_64
                ^findutils@4.6.0%apple-clang@11.0.0 patches=84b916c0bf8c51b7e7b28417692f0ad3e7030d1f3c248ba77c42ede5c1c5d11e,bd9e4e5cc280f9753ae14956c4e4aa17fe7a210f55dd6c84aa60b12d106d47a2 arch=darwin-mojave-x86_64
                    ^libtool@2.4.6%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                    ^texinfo@6.5%apple-clang@11.0.0 patches=12f6edb0c6b270b8c8dba2ce17998c580db01182d871ee32b7b6e4129bd1d23a,1732115f651cff98989cb0215d8f64da5e0f7911ebf0c13b064920f088f2ffe1 arch=darwin-mojave-x86_64
            ^llvm@10.0.1%apple-clang@11.0.0~all_targets+clang~code_signing+compiler-rt~cuda~gold+internal_unwind+libcxx+lld+lldb~mlir~omp_debug~omp_tsan+polly~python~shared_libs~split_dwarf build_type=Release cuda_arch=none patches=332fe65f78b2b4a242045ec2394eee8db631fbcbe27b0016d5e5c859e34f47af arch=darwin-mojave-x86_64
                ^hwloc@1.11.11%apple-clang@11.0.0~cairo~cuda~gl~libudev+libxml2~netloc~nvml~pci+shared arch=darwin-mojave-x86_64
                ^libedit@3.1-20191231%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^perl-data-dumper@2.173%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^python@3.8.5%apple-clang@11.0.0+bz2+ctypes+dbm~debug+libxml2+lzma~nis~optimizations+pic+pyexpat+pythoncmd+readline+shared+sqlite3+ssl~tix~tkinter~ucs4+uuid+zlib patches=0d98e93189bc278fbc37a50ed7f183bd8aaf249a8e1670a465f0db6bb4f8cf87 arch=darwin-mojave-x86_64
                    ^libffi@3.3%apple-clang@11.0.0 patches=26f26c6f29a7ce9bf370ad3ab2610f99365b4bdd7b82e7c31df41a3370d685c0 arch=darwin-mojave-x86_64
                    ^sqlite@3.33.0%apple-clang@11.0.0+column_metadata+fts~functions~rtree arch=darwin-mojave-x86_64
                ^swig@4.0.2%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                    ^pcre@8.44%apple-clang@11.0.0~jit+multibyte+utf arch=darwin-mojave-x86_64
                ^z3@4.8.7%apple-clang@11.0.0+python arch=darwin-mojave-x86_64
                    ^py-setuptools@50.1.0%apple-clang@11.0.0 arch=darwin-mojave-x86_64
            ^py-mako@1.0.4%apple-clang@11.0.0 arch=darwin-mojave-x86_64
                ^py-markupsafe@1.1.1%apple-clang@11.0.0 arch=darwin-mojave-x86_64
    ^hdf5@1.10.7%apple-clang@11.0.0~cxx~debug~fortran+hl~java+mpi+pic+shared~szip~threadsafe api=none arch=darwin-mojave-x86_64
        ^openmpi@3.1.6%apple-clang@11.0.0~atomics~cuda~cxx~cxx_exceptions+gpfs~java~legacylaunchers~lustre~memchecker~pmi~singularity~sqlite3+static~thread_multiple+vt+wrapper-rpath fabrics=none schedulers=none arch=darwin-mojave-x86_64
    ^jsoncpp@1.9.2%apple-clang@11.0.0 build_type=RelWithDebInfo cxxstd=default arch=darwin-mojave-x86_64
    ^libjpeg-turbo@2.0.4%apple-clang@11.0.0 arch=darwin-mojave-x86_64
        ^nasm@2.15.05%apple-clang@11.0.0 arch=darwin-mojave-x86_64
    ^libtiff@4.1.0%apple-clang@11.0.0 arch=darwin-mojave-x86_64
    ^lz4@1.9.2%apple-clang@11.0.0 arch=darwin-mojave-x86_64
    ^netcdf-c@4.7.4%apple-clang@11.0.0~dap~hdf4~jna+mpi~parallel-netcdf+pic+shared arch=darwin-mojave-x86_64
    ^netcdf-cxx@4.2%apple-clang@11.0.0+netcdf4 arch=darwin-mojave-x86_64

If you can extract something from the above that would suggest course of action to correct, please let me know how you do that. I can't.

mclarsen commented 3 years ago

I went and looked at the spack package and the package seems to be setting a lot of cmake defines. One in particular https://github.com/spack/spack/blob/6b70597271232e442b9e729b45adaee02bccf8c0/var/spack/repos/builtin/packages/vtk/package.py#L129 tells it to try to use system libs instead of preferring the libraries that spack built. I wonder what that variable is set to in your build.

Regarding the actual build error that you received, I think I have seen that before with another library. In my case, it happened when gcc was trying to look at apple system headers which include objective c. Then gcc freaked out. Since then I have abandoned trying to use gcc with complex software dependencies. Your spec clearly shows clang, so i don't know how related it is.

markcmiller86 commented 3 years ago

Thanks for taking a look @mclarsen ... can you advise how I can debug what spack+vtk package are trying to do. I used to be able to cd to where it is building and massage things there until I get it working. Now, I can spack cd there but I can't do things like make or maybe re-cmake it, etc. It keeps saying...

Spack compiler must be run from Spack! Input 'SPACK_ENV_PATH' is missing.

Once I set that variable, it complains of another, etc.

mclarsen commented 3 years ago

I haven't been able to get the spack build env stuff to work. I have always found another way to make the build work, but getting into the build is probably the most efficient way to trouble shoot this.

markcmiller86 commented 3 years ago

@griffin28 can you paste here your VTK configuration for macOS 10.14 and/or maybe a CMakeCache.txt file from a recent build you know works there?

cyrush commented 3 years ago

@markcmiller86 I have built with mac most recently via spack -- I can't dive in this week, but perhaps next. In general the fact that xcode shows up isn't necessary a bad sign. The entire default macos dev env (including your command line compilers) derive from xcode.

griffin28 commented 3 years ago

@markcmiller86 CMakeCache.txt file attached.

CMakeCache.txt

markcmiller86 commented 3 years ago

Thanks @griffin28. Unfortunately, a comparison doesn't give me the hints I was hoping for.