[Paraview] Error cross-compiling Catalyst on BG/Q

[Cook, Rich]

Thanks for the secret sauce again.

Now that you mention it, I do remember now large_toc errors trying to get paraview building on our old AIX machine “purple” a while back.  Needed extensive hand-holding then.  But this is gcc and friends, so perhaps GNU has gotten a bit pickier, or been infected with the AIX virus.



On Feb 12, 2015, at 5:12 PM, David E DeMarle <dave.demarle at kitware.com<mailto:dave.demarle at kitware.com>> wrote:


On Thu, Feb 12, 2015 at 7:59 PM, Cook, Rich <cook47 at llnl.gov<mailto:cook47 at llnl.gov>> wrote:
Thanks for all your help!

Sure. Looking forward to having it run on that monster.


I’m now getting a compiler error.  I’m checking with the code developer to determine which compiler chain he uses for his build.  But if I wanted to add an argument to the compiler, how would I do so?


In the CMakeCache.txt of the cross build directory, add them to CMAKE_CXX_FLAGS and such. Or pass them in via -D when you start off.

Building CXX object VTK/IO/Core/CMakeFiles/vtkIOCoreObjects.dir/vtkArrayDataWriter.cxx.o
[ 28%] Built target vtkFiltersCoreObjects
/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld: Common/DataModel/CMakeFiles/vtkCommonDataModelObjects.dir/vtkXMLDataElement.cxx.o(.text+0x2c7c): sibling call optimization to `std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf()' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf()' extern
/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld: Common/DataModel/CMakeFiles/vtkCommonDataModelObjects.dir/vtkXMLDataElement.cxx.o(.text+0x3880): sibling call optimization to `std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf()' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf()' extern
/bgsys/drivers/toolchain/V1R2M2_base/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.7/../../../../powerpc64-bgq-linux/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


Scary one there.

I still have nightmares about "-mminimal-toc or -fno-optimize-sibling-calls".

I started on Mira with XLC and banged my head against a very similar failure. In my case it no matter what I did it always failed to link pvbatch and other big executables.

I never did fix it and instead switched over to the gnu compilers. If you get stuck similarly it may be time to call for backup from IBM.



On Feb 12, 2015, at 4:19 PM, David E DeMarle <dave.demarle at kitware.com<mailto:dave.demarle at kitware.com>> wrote:


On Thu, Feb 12, 2015 at 7:15 PM, Cook, Rich <cook47 at llnl.gov<mailto:cook47 at llnl.gov>> wrote:
/collab/usr/global/tools/Kitware/Catalyst/bgqos_0/catalyst_backend_crossbuild/CMakeFiles/cmTryCompileExec2363604927-CMAKE_REQUIRE_LARGE_FILE_SUPPORT

Is the name of the executable to run.

set( CMAKE_REQUIRE_LARGE_FILE_SUPPORT
     "PLEASE_FILL_OUT-FAILED_TO_RUN"
     CACHE STRING "Result from TRY_RUN" FORCE)

Change that to:
set( CMAKE_REQUIRE_LARGE_FILE_SUPPORT
     0
     CACHE STRING "Result from TRY_RUN" FORCE)

if the return code of that executable is 0

set( CMAKE_REQUIRE_LARGE_FILE_SUPPORT__TRYRUN_OUTPUT
     "PLEASE_FILL_OUT-NOTFOUND"
     CACHE STRING "Output from TRY_RUN" FORCE)

Change that to:
set( CMAKE_REQUIRE_LARGE_FILE_SUPPORT__TRYRUN_OUTPUT
     "I am the very model of a modern major general"
     CACHE STRING "Output from TRY_RUN" FORCE)

If the console output of that executable was "I am the very model of a modern major general"

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909<tel:518-881-4909>

--
✐Richard Cook
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605<tel:%28925%29%20423-9605>
☎ (fax) (925) 423-6961<tel:%28925%29%20423-6961>
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)





--
✐Richard Cook
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150213/6f7d85c9/attachment.html>