[Paraview] Paraview server using off-screen rendering

Thu Jul 23 08:11:19 EDT 2015

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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150723/787feb1e/attachment.html>