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.atk...@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.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 > >
_______________________________________________ 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