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. >> >
_______________________________________________ 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
