Compilation issue with VisIt 2.13.0, OSX

[rustychris]

Related to missing references to FileFunctions::ReadAndProcessDirectory.

[rustychris]

More generally, on High Sierra, using either stock gcc/g++ (i.e. clang) or with homebrew gcc-4.9, cmake dependencies are broken, resulting in failed dependencies referencing miller86. This is presumably related to this bug report.

[rustychris]

cmake dependencies on libz.dylib can be solved by the script fix_depends.sh, after editing the paths therein. This is just a short script to basically follow the suggestion in the above linked bug report.

[rustychris]

ReadAndProcessDirectory shows up in several libraries:

• libengine_par.dylib
• libengine_ser.dylib
• libgui.dylib
• libviewercore_par.dylib
• libviewercore_ser.dylib
• libvisitcommon.dylib

Of those, only visitcommon is currently in the link command (visible with make VERBOSE=1)

visitcommon has that symbol as

$ nm -gU libvisitcommon.dylib | grep ReadAnd
00000000000c3970 T __ZN13FileFunctions23ReadAndProcessDirectoryERKSsPFvPvS1_bblES2_b

which demangles to

FileFunctions::ReadAndProcessDirectory(std::string const&, void (*)(void*, std::string const&, bool, bool, long), void*, bool)

Compare that to the undefined symbol:

__ZN13FileFunctions23ReadAndProcessDirectoryERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEPFvPvS8_bblES9_b

which demangles to

FileFunctions::ReadAndProcessDirectory(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, void (*)(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool, bool, long), void*, bool)

So either there is a bum header which has allowed avtUGRIDFileFormat.C to reference that symbol, or there is a compiler mismatch.

On my system, 2.10.2 PluginVSInstall.cmake gives compiler version as:

# i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

While the system (High Sierra) /usr/bin/clang reports:

Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin17.0.0

Adding in more explicit casts to the call of ReadAndProcessDirectory does not help.

This appears to go back to compiler versions. My Xcode toolchain includes this typedef:

typedef basic_string<char, char_traits<char>, allocator<char> > string;

Which becomes part of the mangled object name, as opposed to the old code which just names std::string.

[rustychris]

At this point, the work-arounds are:

• wait until the VisIt folks release a version compiled with a more recent clang, or
• compile VisIt from source.

[rustychris]

Adding

 -DCMAKE_CXX_FLAGS="-stdlib=libstdc++"

to the cmake invocation yields the same error as when using homebrew g++:

Undefined symbols for architecture x86_64:
"vtkDataSetAlgorithm::SetInputData(vtkDataSet*)", referenced from:
  MeshInfo::ZoneToNode2D(vtkDataArray*, vtkUnstructuredGrid*) in avtUGRIDFileFormat.C.o
"vtkDataSetAlgorithm::GetOutput()", referenced from:
  MeshInfo::ZoneToNode2D(vtkDataArray*, vtkUnstructuredGrid*) in avtUGRIDFileFormat.C.o

But that appears to be define with a compatible mangled name in libvtkCommonExecutionModel

It's possible the GNU compile could be fixed by adding a dependency on libvtkCommonExecutionModel.

[rustychris]

MacOS High Sierra, VisIt 2.10.2

This is a work-around for the compiler version issues, by using libstdc++ from gcc.

Invoke cmake as

cmake -DCMAKE_CXX_FLAGS="-stdlib=libstdc++" .

That causes clang to choose the g++ standard c++ library rather than llvm's.

I am not sure whether this is related, or a separate bug, but this was also necessary to get it compile:

In ugrid.xml, add vtkCommonExecutionModel-6.1 as an extra library. This fixes a missing symbol related vtkDataSetAlgorithm::SetInputData.

<LIBS>
  ${NETCDF_LIB} vtkCommonExecutionModel-6.1
</LIBS>