OsX 10.10 breaking error through CMAKE

[Baris_M_]

Dear all, 

I am trying to compile Fenics in OsX using intel compilers. 

The new edition to my saga is that CMAKE creates test binaries when testing MKL that can not be killed, and leads to a slow corruption of the system (i.e. fonts go crazy etc). The error is reproducible in a macbook pro retina 2011 and mac pro cylinder 2013. 

The "zombie" is created when Teuchos is testing:

 Performing Test CXX_COMPLEX_BLAS_WORKS

The CMAKE is invoked via hashdist with following parameters

${CMAKE} -DCMAKE_INSTALL_PREFIX:PATH="${ARTIFACT}" \
  -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON \
  -DCMAKE_INSTALL_RPATH:STRING="${ARTIFACT}/lib" \
  -DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON \
  -DCMAKE_BUILD_TYPE:STRING=Release \
 -DCMAKE_PREFIX_PATH="${BLAS_DIR};${CMAKE_DIR};${LAPACK_DIR};${MPI_DIR};${NUMPY_DIR};${PYTHON_DIR};${SUITESPARSE_DIR};${SWIG_DIR}" \
  -D CMAKE_CXX_COMPILER:FILEPATH=${MPICXX} -D CMAKE_C_COMPILER:FILEPATH=${MPICC} -D Trilinos_INSTALL_INCLUDE_DIR:PATH=include/trilinos -D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON -D Trilinos_ENABLE_Epetra:BOOL=ON -D Trilinos_ENABLE_ML:BOOL=ON -D Trilinos_ENABLE_PyTrilinos:BOOL=ON -D Trilinos_ENABLE_TESTS:BOOL=OFF -D Trilinos_ENABLE_EXAMPLES:BOOL=OFF -D BUILD_SHARED_LIBS:BOOL=ON -D TPL_ENABLE_MPI:BOOL=ON -D TPL_ENABLE_UMFPACK:BOOL=ON -D BLAS_LIBRARY_NAMES:STRING=mkl_rt -D BLAS_LIBRARY_DIRS:PATH=/opt/intel/mkl/lib/ -D LAPACK_LIBRARY_NAMES:STRING=mkl_rt -D LAPACK_LIBRARY_DIRS:PATH=/opt/intel/mkl/lib/ -D UMFPACK_INCLUDE_DIRS:PATH=${SUITESPARSE_DIR}/include/suitesparse -D UMFPACK_LIBRARY_DIRS:PATH=${SUITESPARSE_DIR}/lib -D UMFPACK_LIBRARY_NAMES:STRING="umfpack;cholmod;camd;ccolamd;colamd;amd;suitesparseconfig" -D SWIG_EXECUTABLE:FILEPATH=${SWIG_EXECUTABLE} -D PYTHON_EXECUTABLE:FILEPATH=${PYTHON} \
  ..
)
${CMAKE} --build . -- -j ${HASHDIST_CPU_COUNT}

The zombie binary is generated with the following link.txt

mpic++    -DCXX_COMPLEX_BLAS_WORKS -Wl,-search_paths_first -Wl,-headerpad_max_install_names  -Lhashdist/bld/blas/orqin7luuh5d/lib  -L.hashdist/bld/cmake/llreawl5z57x/lib  -L.hashdist/bld/lapack/xvzyk5hqp7ew/lib  -L.hashdist/bld/mpi/gi7gvjksd6f3/lib  -L.hashdist/bld/numpy/pwyxrcqhcikq/lib  -L/.hashdist/bld/python/2y62fdg7o42s/lib  -L/.hashdist/bld/suitesparse/47udu3z4wfph/lib  -L.hashdist/bld/swig/mev4ahg24s3p/lib   CMakeFiles/cmTryCompileExec1717385958.dir/src.cxx.o  -o cmTryCompileExec1717385958  /opt/intel/mkl/lib/libmkl_rt.dylib

I tried manually, and ended up with the zombie process myself, and had to reboot the system, even I initiated the process with gdb. 

The test is this:

#include <complex>

#define F77_BLAS_MANGLE(name,NAME) name ## _

extern "C" {
  std::complex<float> F77_BLAS_MANGLE(cdotc,CDOTC)(
    const int* n, const  std::complex<float> x[], const int* incx,
    const std::complex<float> y[], const int* incy);
}

int main() {
  const int NUM=2;
  const int INC=1;
  std::complex<float> f[NUM];
  const std::complex<float>
    ONE = std::complex<float>(1.0,0.0),
    TWO = std::complex<float>(2.0,0.0);
  f[0] =  ONE;
  f[1] =  ONE;
  const std::complex<float> ret =
    F77_BLAS_MANGLE(cdotc,CDOTC)(&NUM, f, &INC, f, &INC);
  return (ret == TWO ? 0 : 1);
}

[mecej4]

I should consider it an OSX bug if you cannot kill a misbehaving user mode program, regardless of whether you used MKL, Cmake, and other tools to build the program. In other words, if a program that would cause an access violation in WIndows or a seg-fault in Linux causes a hung machine under OSX, you have a defective OS, and should inform Apple.

[Baris_M_]

Mecej4: Thanks, I am forwarding this in OsX yosemite support communities as well. Would you please let me know if you happen to come by to a workaround?   

[mecej4]

Sorry, I don't use Apple hardware.