Hello, Ooops.. I was trying to see if I did anything wrong and saw that I addressed my reply to only Chuck. I'm sorry (reply vs. reply all).
I've uploaded the CMakeCache.txt here https://psu.box.com/s/xsrbpsu73exqmz6v1rsy8jy2mtyzabhk. This is the error message when using the verbose option. [ 4%] Built target vtkWrappingTools make -f VTK/Wrapping/Tools/CMakeFiles/vtkWrapHierarchy.dir/build.make VTK/Wrapping/Tools/CMakeFiles/vtkWrapHierarchy.dir/depend make[2]: Entering directory `/lustre/medusa/gantech/software/Paraview-v4.3.1' cd /lustre/medusa/gantech/software/Paraview-v4.3.1 && /nics/e/sw/xc30_cle5.2_pe2014-09/cmake/2.8.12.2/sles11.3_gnu4.3.4/bin/cmake -E cmake_depends "Unix Makefiles" /nics/d/home/gantech/softw are/ParaView-v4.3.1-source /nics/d/home/gantech/software/ParaView-v4.3.1-source/VTK/Wrapping/Tools /lustre/medusa/gantech/software/Paraview-v4.3.1 /lustre/medusa/gantech/software/Paraview-v4 .3.1/VTK/Wrapping/Tools /lustre/medusa/gantech/software/Paraview-v4.3.1/VTK/Wrapping/Tools/CMakeFiles/vtkWrapHierarchy.dir/DependInfo.cmake --color= make[2]: Leaving directory `/lustre/medusa/gantech/software/Paraview-v4.3.1' make -f VTK/Wrapping/Tools/CMakeFiles/vtkWrapHierarchy.dir/build.make VTK/Wrapping/Tools/CMakeFiles/vtkWrapHierarchy.dir/build make[2]: Entering directory `/lustre/medusa/gantech/software/Paraview-v4.3.1' Linking C executable ../../../bin/vtkWrapHierarchy-pv4.3 cd /lustre/medusa/gantech/software/Paraview-v4.3.1/VTK/Wrapping/Tools && /nics/e/sw/xc30_cle5.2_pe2014-09/cmake/2.8.12.2/sles11.3_gnu4.3.4/bin/cmake -E cmake_link_script CMakeFiles/vtkWrapHi erarchy.dir/link.txt --verbose=1 /opt/cray/craype/2.2.1/bin/cc -O3 -DNDEBUG -Wl,--fatal-warnings -Wl,--no-undefined -lc -Wl,--fatal-warnings -Wl,--no-undefined -lc CMakeFiles/vtkWrapHierarchy.dir/vtkWrapHierarchy.c.o -o ../../../bin/vtkWrapHierarchy-pv4.3 -rdynamic ../../../lib/libvtkWrappingTools-pv4.3.a /usr/lib/../lib64/libpthread.a(lowlevellock.o): In function `__lll_lock_wait_private': /usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:81: multiple definition of `__lll_lock_wait_private' /usr/lib/../lib64/libc.a(libc-lowlevellock.o):/usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:81: first defined here /usr/lib/../lib64/libpthread.a(lowlevellock.o): In function `__lll_unlock_wake_private': /usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:323: multiple definition of `__lll_unlock_wake_private' /usr/lib/../lib64/libc.a(libc-lowlevellock.o):/usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:323: first defined here /usr/bin/ld: link errors found, deleting executable `../../../bin/vtkWrapHierarchy-pv4.3' collect2: error: ld returned 1 exit status make[2]: *** [bin/vtkWrapHierarchy-pv4.3] Error 1 make[2]: Leaving directory `/lustre/medusa/gantech/software/Paraview-v4.3.1' make[1]: *** [VTK/Wrapping/Tools/CMakeFiles/vtkWrapHierarchy.dir/all] Error 2 make[1]: Leaving directory `/lustre/medusa/gantech/software/Paraview-v4.3.1' make: *** [all] Error 2 On Thu, Jul 23, 2015 at 8:11 AM, Chuck Atkins <[email protected]> wrote: > Hi Ganesh, > > Can you post your CMakeCache.txt? Also, if you build with "make > VERBOSE=1" that will give the full command that gets executed for the > failing link step. Posting both of those will be helpful. > > - Chuck > > On Wed, Jul 22, 2015 at 10:37 PM, Ganesh Vijayakumar < > [email protected]> wrote: > >> Dear Chuck, >> >> Finally, I got this done. I could get paraview to configure without >> giving any errors. I removed the build directory and started afresh. >> However, it fails at the same place during the compilation. Could you >> advise as to what might be the problem. >> >> Linking C executable ../../../../bin/vtkmkg3states-pv4.3 >> /usr/lib/../lib64/libpthread.a(lowlevellock.o): In function >> `__lll_lock_wait_private': >> /usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:81: >> multiple definition of `__lll_lock >> _wait_private' >> >> /usr/lib/../lib64/libc.a(libc-lowlevellock.o):/usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowleve >> llock.S:81: first defined here >> /usr/lib/../lib64/libpthread.a(lowlevellock.o): In function >> `__lll_unlock_wake_private': >> /usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:323: >> multiple definition of `__lll_unl >> ock_wake_private' >> >> /usr/lib/../lib64/libc.a(libc-lowlevellock.o):/usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowleve >> llock.S:323: first defined here >> /usr/bin/ld: link errors found, deleting executable >> `../../../../bin/vtkmkg3states-pv4.3' >> collect2: error: ld returned 1 exit status >> make[2]: *** [bin/vtkmkg3states-pv4.3] Error 1 >> make[1]: *** >> [VTK/ThirdParty/tiff/vtktiff/CMakeFiles/vtkmkg3states.dir/all] Error 2 >> make: *** [all] Error 2 >> >> >> ganesh >> >> On Thu, Jul 16, 2015 at 2:19 PM Chuck Atkins <[email protected]> >> wrote: >> >>> If it's a problem with HDF5 library, I'm not sure where I need to point >>>>>> to the system installation. >>>>>> >>>>> If you load the cray-hdf5 module, that will set the HDF5_DIR >>>>> environment variable to the correct location. Unfortunately, CMake uses >>>>> the HDF5_ROOT variable instead to look for it so you'll neet to set it >>>>> accordingly. >>>>> >>>> I don't have much experience with cmake, but can I set additional >>>> variables in the ccmake window? Should this variable show up there asking >>>> to be set if you turn on the advanced mode toggle? >>>> >>> >>> Different find modules work differently. The FindHDF5 module uses the >>> HDF5_ROOT environment variable (not CMake variable, which is why it won't >>> show up in the ccmake UI) as a hint for where to search, hence exporting it >>> as an env var prior to running CMake. You'll also want to be sure to >>> specify to use an external HDF5 rather than ParaView building it's own: >>> >>> -DVTK_USE_SYSTEM_HDF5:BOOL=ON >>> >>> >>> CMAKE_CXX_FLAGS -L/lustre/medusa/gantech/ >>>> software/mesa-10.6.0/lib >>>> >>> ... >>> >>>> CMAKE_C_FLAGS -L/lustre/medusa/gantech/ >>>> software/mesa-10.6.0/lib >>>> >>> ... >>> >>>> CMAKE_EXE_LINKER_FLAGS -L/lustre/medusa/gantech/ >>>> software/mesa-10.6.0/lib >>>> >>> >>> Instead of setting these in the compiler flags, it's better to tell >>> ParaView where to explicitly find the libraries and to configure >>> accordingly for OSMesa. You can pass these as command line arguments to >>> cmake or ccmake with -D, or set them in the ccmake UI: >>> >>> -DOPENGL_INCLUDE_DIR:PATH= >>> -DOPENGL_xmesa_INCLUDE_DIR:PATH= >>> -DOPENGL_gl_LIBRARY:FILEPATH= >>> -DOPENGL_glu_LIBRARY:FILEPATH= >>> -DOSMESA_INCLUDE_DIR:PATH=/lustre/medusa/gantech/ >>> software/mesa-10.6.0/include >>> -DOSMESA_LIBRARY:FILEPATH=/lustre/medusa/gantech/ >>> software/mesa-10.6.0/lib/libOSMesa.a >>> -DVTK_OPENGL_HAS_OSMESA:BOOL=ON >>> -DVTK_USE_X:BOOL=OFF >>> >>> >>> >>>> CMAKE_Fortran_COMPILER /opt/gcc/4.9.2/bin/gfortran >>>> >>> >>> Not that it will really matter since we're not compiling Fortran code, >>> but this should be /opt/cray/craype/2.2.1/bin/ftn >>> >>> >>> MPI_CXX_LIBRARIES /opt/cray/mpt/7.1.3/gni/ >>>> mpich2-gnu/49/lib/ >>>> >>> ... >>> >>>> MPI_C_LIBRARIES /opt/cray/mpt/7.1.3/gni/ >>>> mpich2-gnu/49/lib/ >>>> >>> ... >>> >>>> MPI_LIBRARY /opt/cray/mpt/7.1.3/gni/ >>>> mpich2-gnu/49/lib >>>> >>> >>> It does look like the wrappers are correctly getting used for mpicc and >>> mpiCC and you can see the include dirs getting set accordingly, but these >>> do not look right. Which version of CMake are you using? Here's what I >>> get using CMake 3.2.3 (current cmake) on a Cray XC30 when not setting any >>> MPI variables, just letting CMake auto-detect them by enabling >>> ParaView_USE_MPI=ON: >>> >>> MPI_CXX_COMPILER >>> /opt/cray/craype/2.1.0/bin/CC >>> MPI_CXX_COMPILE_FLAGS >>> >>> MPI_CXX_INCLUDE_PATH >>> >>> MPI_CXX_LIBRARIES >>> >>> MPI_CXX_LINK_FLAGS >>> >>> MPI_CXX_NO_INTERROGATE >>> /opt/cray/craype/2.1.0/bin/CC >>> MPI_C_COMPILER >>> /opt/cray/craype/2.1.0/bin/cc >>> MPI_C_COMPILE_FLAGS >>> >>> MPI_C_INCLUDE_PATH >>> >>> MPI_C_LIBRARIES >>> >>> MPI_C_LINK_FLAGS >>> >>> MPI_C_NO_INTERROGATE >>> /opt/cray/craype/2.1.0/bin/cc >>> MPI_EXTRA_LIBRARY >>> MPI_EXTRA_LIBRARY-NOTFOUND >>> MPI_Fortran_COMPILER >>> /opt/cray/craype/2.1.0/bin/ftn >>> MPI_Fortran_COMPILE_FLAGS >>> >>> MPI_Fortran_INCLUDE_PATH >>> >>> MPI_Fortran_LIBRARIES >>> >>> MPI_Fortran_LINK_FLAGS >>> >>> MPI_Fortran_NO_INTERROGATE >>> /opt/cray/craype/2.1.0/bin/ftn >>> MPI_LIBRARY MPI_LIBRARY-NOTFOUND >>> >>> Because the Cray wrappers automatically add the mpi libs and headers >>> (behaving like mpiCC), then the MPI code should compile without any >>> additional flags. >>> >> > -- ganesh
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
