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

Thu Feb 25 11:44:28 EST 2016

Hi Tim,

Yep, you did update the list a while ago. I just wanted to make sure you
weren't stuck on something that I could potentially help with.

Good luck!
Andy

On Thu, Feb 25, 2016 at 11:28 AM, Tim Gallagher <tim.gallagher at gatech.edu>
wrote:

> Hi Andy,
>
> Sorry, I thought I updated the list awhile ago!
>
> Using the scripts that Richard provided, I was able to build on Copper and
> could run the FEM coprocessing demo. But I got stuck trying to get our code
> to link against it. Our code is set up using the Catamount toolchain file
> and so things like dynamic linking don't work with the way we have been
> doing our build. So, I need to try and figure out how to change our build
> system setup to get everything to work properly. It doesn't work if we just
> stop using the toolchain.
>
> I haven't figured that bit out yet; it's on my todo list. But I was able
> to get PV to build with Richard's script.
>
> I also could not get the script that comes with the superbuild to work
> either, but did not dig into it because I had something that did work.
>
> Tim
>
> ------------------------------
> *From: *"Andy Bauer" <andy.bauer at kitware.com>
> *To: *"Chuck Atkins" <chuck.atkins at kitware.com>
> *Cc: *"tim gallagher" <tim.gallagher at gatech.edu>, "paraview" <
> paraview at paraview.org>
> *Sent: *Thursday, February 25, 2016 11:21:27 AM
> *Subject: *Re: [Paraview] [Non-DoD Source] Building on Cray systems
>
> 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/a27d8bfd/attachment.html>