[Paraview] [Non-DoD Source] Building on Cray systems

[Chuck Atkins]

Hi Tim,

When building CMake on a Cray, you'll want to build using the host system
compilers, i.e. /usr/bin/gcc and /usr/bin/g++, not with the cray compiler
wrappers.  Usually I just do:

module purge
CC=/usr/bin/gcc CXX=/usr/bin/g++ /path/to/cmake_source/bootstrap
--prefix=/path/to/cmake/install --parallel=8
make -j8 install

The resulting CMake binary can then run on either the login nodes or
compute nodes and target anything that CMake supports.  I would also
suggest building CMake from either the latest git master branch or the
current 3.5 release candidate.  I've added a new platform file for the Cray
Linux Environment that knows how to introspect the compiler wrappers,
correctly deal with static / shared, etc, not currently available in the
3.4 release.  You can use it by loading your appropriate PrgEnv module
setting CMAKE_SYSTEM_NAME=CrayLinuxEnvironment or using a toolchain file
like this:

# The name of the target operating system
set(CMAKE_SYSTEM_NAME CrayLinuxEnvironment) # This handles all the oddball
Cray stuff

if(DEFINED ENV{ASYNCPE_DIR})    # Older Cray programming environment
  set(COMP_DIR $ENV{ASYNCPE_DIR})
elseif(DEFINED ENV{CRAYPE_DIR}) # Newer Cray programming environment
  set(COMP_DIR $ENV{CRAYPE_DIR})
else()
  message(FATAL_ERROR "Unable to determine compiler dir")
endif()

# Set the compilers
set(CMAKE_C_COMPILER       ${COMP_DIR}/bin/cc)
set(CMAKE_CXX_COMPILER     ${COMP_DIR}/bin/CC)
set(CMAKE_Fortran_COMPILER ${COMP_DIR}/bin/ftn)


- Chuck

On Fri, Feb 5, 2016 at 5:36 AM, Tim Gallagher <tim.gallagher at gatech.edu>
wrote:

> Sorry if you get this multiple times -- the original was blocked from the
> PV list because the output log was too big. I can send the log I referred
> to off-list to anybody who is interested.
>
> --------------------------------------------------
>
> Good morning!
>
> Thanks Andy and Richard for the advice.
>
> After banging my head on my keyboard for most of the day yesterday,
> neither approach worked on Copper.
>
> For Andy's suggestion of building pv5.0 with the Cray cross compiling
> script, I got a bunch of errors towards the end. It looks like many things
> did build, but then those errors about an unknown system kicked in and it
> seemed to all fall apart. I attached the output log as cray_build_pv5.0.txt
>
> Richard, I tried your setup as well. I initially was trying to avoid the
> building CMake step but eventually something in the ParaviewSuperbuild
> failed because it said it needed CMake 2.8.11 and Copper only has 2.8.10.
> So, I took a step back and tried to build CMake. When I just do what is in
> your script -- configure and then make -- the build fails quickly because
> it says it cannot statically link shared libraries. So I tried to build
> CMake using the Catamount.cmake toolchain that we use for our application
> code as well. The initial configuration took over an hour, it sits at 95%
> for a long time going through the portion where it looks for various
> headers/features. But eventually it finishes and I tried to build but that
> failed. I get:
>
> tgallagh at copper01:~/cmake/build> make
> [  3%] Built target cmsys
> [  4%] Built target cmsys_c
> [  6%] Built target cmzlib
> [  6%] Building C object
> Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/strerror.c.o
> /u/tgallagh/cmake/cmake/Utilities/cmcurl/lib/strerror.c:32:6: error:
> #error "strerror_r MUST be either POSIX, glibc or vxworks-style"
>  #    error "strerror_r MUST be either POSIX, glibc or vxworks-style"
>       ^
> make[2]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/strerror.c.o]
> Error 1
> make[1]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/all] Error 2
>
> So taking a big step backwards here to look at the big picture -- am I
> (and our lab) just using Cray systems in a fundamentally incorrect way?
> We've always struggled to get things to build when we never have had issues
> with SGI/Intel, BlueGene, or IBM machines (even when they were using
> PowerPC). We used to have all these same issues with our CFD code on Cray
> as well and the only solution we found was to build all of our codes'
> libraries statically and drop support for shared libraries.
>
> I appreciate the help with the scripts. If there's any follow-up advice on
> what I'm doing wrong in both/either approach, that would be great.
>
> Thanks,
>
> Tim
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160208/163ebdc0/attachment.html>