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.gallag...@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@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