On Fri, Nov 1, 2013 at 1:34 PM, Francesco Ballarin <
francesco.balla...@polimi.it> wrote:
> Dear libMesh developers,
> I'm having some troubles compiling libMesh on a BG/Q architecture with XL
> compilers. I would like to report some issues and ask for your help.
>
>
> 1. The first issue I ran into has been that xlc was not properly detected.
> It sufficed to change line 294 of m4/compiler.m4 in
> is_ibm_xlc="`($CXX -v 2>&1) | egrep -i 'xlc'`"
> (and boostrap) to fix this.
>
Thanks, I think this stems from some much older version of xlC not even
recognizing '-v' as a legitimate command line option, but we can probably
fix this now.
> 2. Exodus fails to build since it seems that XL Fortran compiler requires
> a different syntax when defining a preprocessor macro (-WF,-D instead of
> -D). A simple workaround is
> ===
> cd contrib/exodusii/v5.22/exodus
> make -k
> sed -i 's/-D/-WF,-D/g' Makefile
> make
> ===
>
Why on earth would IBM do this? It differs from literally every other
compiler that I've ever seen. I don't know if there's a built-in autoconf
test for "how to #define stuff on the compile line" but that seems like
that's what we'd need here to fix this the right way.
3. libMesh library is built correctly but I cannot link executables.
>
> The error that I get is:
> ===
> /bgsys/drivers/ppcfloor/gnu-linux/powerpc64-bgq-linux/bin/ld:
> /bgsys/drivers/V1R2M0/ppc64/comm/sys-fast/lib/libpami.a(component-pami--CAPI.cnk.o)(.text._ZNSt8_Rb_treeIjSt4pairIKjjESt10_Select1stIS2_ESt4lessIjESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E[_ZNSt8_Rb_treeIjSt4pairIKjjESt10_Select1stIS2_ESt4lessIjESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E]+0xbc):
> sibling call optimization to
> `_ZNSt8_Rb_treeIjSt4pairIKjjESt10_Select1stIS2_ESt4lessIjESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E'
> does not allow automatic multiple TOCs; recompile with -mminimal-toc or
> -fno-optimize-sibling-calls, or make
> `_ZNSt8_Rb_treeIjSt4pairIKjjESt10_Select1stIS2_ESt4lessIjESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E'
> extern
> ===
>
> I tried adding -mminimal-toc or -fno-optimize-sibling-calls or
> -qminimaltoc to CXXFLAGS without any luck.
>
VTK guys seem to report [0] that adding -fno-optimize-sibling-calls did
work for them. Maybe try again, but add it to libmesh_CXXFLAGS as well,
reconfigure, and run 'make V=1' to confirm that it really is being passed.
[0] http://visitusers.org/index.php?title=Really_Large_Tree
My configure options are as follows:
> ===
> export CXX="mpixlcxx_r"
> export CC="mpixlc_r"
> export FC="mpixlf90_r"
> export F77="mpixlf77_r"
> bash $SRC_DIR/configure --enable-mpi --with-mpi="$BGQ_XL_HOME"
> --with-cxx=$CXX --with-cc=$CC --with-fc=$FC --with-f77=$F77
> --disable-shared --enable-all-static --with-methods="dbg" --enable-petsc
> --enable-metis --with-metis=PETSc --prefix="$INSTALL_DIR"
> ===
>
> Everything works fine removing "--enable-petsc" from the configuration
> options, so the problem appears to be caused by PETSc.
> I think however that the PETSc installation is ok, since PETSc examples
> and tutorials compile (and link) fine.
>
No idea why removing PETSc would fix this multiple TOCs issue, was your
Petsc built with --with-clanguage=cxx (or whatever the current name of that
option is)?
Thanks for your report, it would be nice to get libmesh working with xlC on
a modern IBM computer...
--
John
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
