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 <[email protected]<mailto:[email protected]>> wrote: On Thu, Feb 12, 2015 at 7:59 PM, Cook, Rich <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: On Thu, Feb 12, 2015 at 7:15 PM, Cook, Rich <[email protected]<mailto:[email protected]>> 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)
_______________________________________________ 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
