[Paraview] Paraview server using off-screen rendering

[Ganesh Vijayakumar]

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/d79e555b/attachment.html>