[Paraview] Compiling Paraview errors on Oak Ridge HPC Titan

Fri Jun 7 13:38:14 EDT 2013

Try using the paraview superbuild to build static lib paraview on titan.

To do that do a git fetch from:
git://paraview.org/ParaViewSuperbuild.git

Then make two build directories.

In the first, set CROSS_BUILD_STAGE to "TOOLS", set CROSS_TARGET to
"xk7_gnu", and build.

In the next, set CROSS_BUILD_STAGE to "CROSS", and point
PARAVIEW_HOSTTOOLS_DIR to the first build directory and build.

If it doesn't work let us know. It has been a couple of months since I
built there, and until I get a nightly dashboard up on titan, I can't
assert that something hasn't broken it.

Note that this the build will use the gnu compiler chain. I haven't tried
any of the other compilers recently on a cray, but I'm sure we can make it
work and then add another CROSS_TARGET for them if your codes require
something else.

As Burlen suggested, with static builds library order can easily be a
sticking point that result in late stage linking errors. As a workaround
you can make VERBOSE=1 to see the link line, and edit it and reenter it to
see if this is the problem. The longer term fix for me was to add the
MPI library set to the HDF5_LIBRARIES set, which makes cmake infer the
proper link order. (see the bgp_xlc target's ParaViewDefaults.cmake to see
that approach).

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Fri, Jun 7, 2013 at 12:11 PM, Burlen Loring <bloring at lbl.gov> wrote:

>
> You may be missing a gni library? use nm on the .a files to figure out if
> it has the missing symbols. Also with static linking the order you list the
> libraries matters. in your case you'll need to list the gni library(ies)
> before the mpich libarary on the link line. You could check if that's your
> problem by running "make VERBOSE=1" and examining the order that's used.
> You could potentiall force the linker to not care about library order by
> enclosing mpi and it's dependencies in --start-group , --end-group linker
> options...
>
> It's a little more work but in my experience things will go smoother for
> you if you avoid the CC wrappers when building ParaView. also pgi is used
> relatively rarely compared to gcc so you're asking for problems. Fine if
> you're prepared to dig in a deal with them, but if you want it just to
> work, then use gcc.
>
> to avoid cc wrappers one thing you need to do is find mpi and its
> dependencies. if you run "CC --verbose" you can see the link options used
> by CC. You want to extract just the ones you need and no others. then since
> you want static linking you might need determine the order of the
> libraries. to give you some ideas about what you're after, I'll attach
> result of this process from NERSC's Cray XC30 Edison, but watch out I used
> dynamic linking so it's not exactly what you need.
>
> hope this will help
>
>
> On 06/07/2013 07:02 AM, Hong Yi wrote:
>
>  I’ve been working on building ParaView on Oak Ridge HPC Titan (Cray HPC
> system) for its coprocessing/catalyst libraries to be linked to PHASTA
> simulation code running on Titan for in-situ coprocessing as well as live
> monitoring via pvserver which are already built and can run successfully on
> Oak Ridge visualization cluster Lens. There are some “undefined references”
> errors while building ParaView on Titan which I already contacted Titan HPC
> support specialist but we are currently out of ideas on what to try next to
> fix these compilation errors. So I am hoping to get some ideas from people
> on this list who might have experienced such issues and might have some
> fresh ideas to help us move forward. ****
>
> ** **
>
> Specifically, we have to build ParaView on titan with “BUILD_SHARED_LIB”
> off so it can be statically linked to PHASTA simulation code and run on the
> Titan compute nodes. I set “apron” as MPIEXEC, set Cray pgi  wrapper
> compilers CC, cc, ftn as MPI_CXX_COMPILER, MPI_C_COMPILER, and
> MPI_FORTRAN_COMPILER, set Cray_mpich2/5.6.3 as MPI libraries to link to.
>  First, I tried to use gnu compilers as CMAKE compilers and was able to
> configure and then build ParaView, but got the following “undefined
> references” errors in libmpich.a such as the following when it was about
> 51% built:****
>
> ** **
>
> ------------------------------------****
>
> Linking CXX executable ../../../bin/vtkpython****
>
> /opt/cray/mpt/5.6.3/gni/mpich2-pgi/119/lib/libmpich.a(gni_poll.o): In
> function `MPID_nem_gni_process_async_mhndl_ack':****
>
> gni_poll.c:(.text+0x3d): undefined reference to `GNI_SmsgRelease'****
>
> gni_poll.c:(.text+0x58): undefined reference to `gni_err_str'****
>
> --------------------------------****
>
> ** **
>
> Then as suggested by HPC support specialist, I changed to use cray pgi
> wrapper compilers CC, cc, ftn as corresponding CMAKE compilers (rather than
> use gnu compilers as I initially did), however, I got the following
> “undefined references” errors when it was about 19% built:****
>
> ** **
>
> --------------------------------****
>
> /ccs/proj/nfi010/ParaView/ParaView-3.98.1-source/VTK/Utilities/KWSys/vtksys/SystemTools.cxx:1768:
> warning: Using 'getpwnam' in statically linked applications requires at
> runtime the shared libraries from the glibc version used for linking****
>
> /opt/pgi/12.10.0/linux86-64/12.10/lib/libCmpz.a(eh_util.o): In function
> `std::uncaught_exception(void)':****
>
> eh_util.c:(.text+0x307): undefined reference to `__zceh_uncaught_exception'
> ****
>
> /usr/bin/ld: link errors found, deleting executable
> `../../../bin/vtkHashSource-pv3.98'****
>
> child process exit status 1: /sw/xk6/altd/bin/ld****
>
> make[2]: *** [bin/vtkHashSource-pv3.98] Error 2****
>
> make[1]: *** [VTK/Utilities/HashSource/CMakeFiles/vtkHashSource.dir/all]
> Error 2****
>
> make: *** [all] Error 2****
>
> ---------------------------------------****
>
> ** **
>
> Not sure why pgi compiler is trying to use glibc which then leads to the
> undefined reference error as shown above with libCmpz.a. This problem does
> not happen if we use gnu compilers for CMake compilers but we got another
> set of undefined references in libmpich.a as described above. ****
>
> ** **
>
> Anybody has any ideas on what is wrong here and what we should try next to
> resolve these “undefined references” errors?****
>
> ** **
>
> Many thanks for any suggestions you can provide!****
>
> ** **
>
> Hong****
>
> ** **
>
> ****
>
>
> _______________________________________________
> 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
>
> Follow this link to subscribe/unsubscribe:http://www.paraview.org/mailman/listinfo/paraview
>
>
>
> _______________________________________________
> 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
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20130607/36d8e597/attachment-0001.htm>