[Paraview] Paraview server using off-screen rendering
Ganesh Vijayakumar
ganesh.iitm at gmail.com
Sat Jul 25 19:56:36 EDT 2015
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 <chuck.atkins at kitware.com>
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 <
> ganesh.iitm at gmail.com> 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 <chuck.atkins at kitware.com>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150725/637b3aeb/attachment.html>
More information about the ParaView
mailing list