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

Andy Bauer andy.bauer at kitware.com
Thu Feb 25 11:21:27 EST 2016


Hi Tim,

Were you able to get Catalyst built on any of those machines? I briefly
tried on Copper and Garnet with the superbuild but hit some failure that I
didn't investigate further.

Best,
Andy

On Mon, Feb 8, 2016 at 2:51 PM, Chuck Atkins <chuck.atkins at kitware.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20160225/cca18299/attachment.html>


More information about the ParaView mailing list