September 2015 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Jeff Hammond 23 Sep '15

23 Sep '15

For what it's worth, I have actually used get_command_argument in my own code and just now confirmed that it works just fine with Intel 16 in a small test program. It would be helpful to disambiguate that from all the shared library discussion. The other solution is to use ISO C11* as God intended and stop mucking around with all these flowery languages. Jeff * It is true that no compiler yet supports C11 threads, but that is because C compiler developers know better than to troll the PETSc team with programming atrocities like threads. On Tue, Sep 22, 2015 at 9:16 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Tue, 22 Sep 2015, Blaise A Bourdin wrote: > > > With the later configuration, it looks like what matters is the order in > which -lmpifort and -lifcore are listed: > > This one works: > > mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress > -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 > -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o > -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib > -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc > -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib > -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib > -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib > -lifcore -lmpifort > > > > This one does not: > > mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress > -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 > -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o > -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib > -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc > -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib > -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib > -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib > -lmpifort -lifcore > > Does linking with -lifcore vs > > /opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a > make a difference? > > And what do you have for: > > cd /opt/HPC/mpich-3.1.4-intel16.0/lib > ls > nm -Ao libmpiifort.* |grep get_command_argument > > BTW: I'm assuming you have sept 20 or newer petsc master branch. > > Satish > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Jeff Hammond 23 Sep '15

23 Sep '15

What the specification document says is irrelevant, since every implementation still supports the C++ bindings. They can be disabled explicitly in MPICH (and derivatives) via MPICH_SKIP_MPICXX and in OpenMPI with OMPI_SKIP_MPICXX. Jeff On Tue, Sep 22, 2015 at 2:11 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: > > And then the MPI c++ libraries.. > > The current MPI standard does not contain C++ bindings. > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Fwd: OSX and valgrind
by Patrick Sanan 23 Sep '15

23 Sep '15

The valgrind-devel port from MacPorts currently seems to work as well (on my OS X 10.10 system).

1 0

OSX and valgrind
by Dave May 23 Sep '15

23 Sep '15

Hey guys, Yesterday valgrind rolled out a new release which _actually_ works on OSX. http://valgrind.org/downloads/current.html I tried it on my 10.9 system using this configure line ./configure --prefix=/Users/dmay/software CC=/opt/local/bin/gcc-mp-4.8 --enable-only64bit --build=amd64-darwin I did encounter this error during make m_syscall.c:708:1: error: unknown type name '__private_extern__' __private_extern__ UWord ^ m_syscall.c:709:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'do_syscall_unix_WRK' do_syscall_unix_WRK ( UWord a1, UWord a2, UWord a3, /* rdi, rsi, rdx */ ^ m_syscall.c:732:1: error: unknown type name '__private_extern__' __private_extern__ UWord ^ m_syscall.c:733:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'do_syscall_mach_WRK' do_syscall_mach_WRK ( UWord a1, UWord a2, UWord a3, /* rdi, rsi, rdx */ ^ m_syscall.c: In function 'vgPlain_do_syscall': m_syscall.c:1017:10: warning: implicit declaration of function 'do_syscall_unix_WRK' [-Wimplicit-function-declaration] wLO = do_syscall_unix_WRK(a1,a2,a3,a4,a5,a6,a7,a8, ^ m_syscall.c:1022:10: warning: implicit declaration of function 'do_syscall_mach_WRK' [-Wimplicit-function-declaration] wLO = do_syscall_mach_WRK(a1,a2,a3,a4,a5,a6,a7,a8, ^ make[3]: *** [libcoregrind_amd64_darwin_a-m_syscall.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Following the instructions here http://superuser.com/questions/630674/valgrind-installation-errors-on-osx-1… I was successful building valgrind. Tests revealed it functions correctly. My buddy using OSX 10.10 pulled it down from HomeBrew and this worked out of the box. About f***ing time :) Cheers, Dave

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Jed Brown 23 Sep '15

23 Sep '15

Satish Balay <balay(a)mcs.anl.gov> writes: > There is no [easy] automatic way of figuring out this reduced link > command that might work. Almost all such problems are caused by shared libraries being broken or improperly linked on too many HPC systems. If shared libraries are used correctly, then using PETSc amounts to passing -lpetsc. If you call another library, you also link it directly (even if PETSc also links to it transitively). That's all. Note that almost all HPC machines are based on Linux and that shared libraries have had well-defined fully-functional semantics on Linux for 20+ years, so functionality is not a matter of a new implementation, but rather just not breaking something that works. Facilities and vendors need constant reminders that functional and properly-used shared libraries are important. As for PETSc, I actually attempt a simplified link line (e.g., in FindPETSc.cmake) and only fall back to the unwieldy beast when it fails. (This happens for static libraries, but also when shared libraries are foobared.)

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Satish Balay 23 Sep '15

23 Sep '15

On Wed, 23 Sep 2015, Blaise A Bourdin wrote: > > > On Sep 22, 2015, at 11:16 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > On Tue, 22 Sep 2015, Blaise A Bourdin wrote: > > > >> With the later configuration, it looks like what matters is the order in which -lmpifort and -lifcore are listed: > >> This one works: > >> mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lifcore -lmpifort > >> > >> This one does not: > >> mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lmpifort -lifcore > > > > Does linking with -lifcore vs > > /opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a > > make a difference? > It does. When I specify the path explicitly, the build works, regardless of the order in which libmpifort and libifcore are listed. > > > > And what do you have for: > > > > cd /opt/HPC/mpich-3.1.4-intel16.0/lib > > ls > > nm -Ao libmpiifort.* |grep get_command_argument > This gives nothing at all: > bourdin@galerkin:lib $ nm -Ao lib* |grep -i command > bourdin@galerkin:lib $ > Here is my guess: Presumably you have libmpifort.dylib When libmpifort.dylib was created 'libifcore.a' was used in the link linke - thus some of the compiler symbols were pulled into libmpifort.dylib. When libpetsc.dylib [or an example binary] is created the duplcate symbols in libmpifort.dylib is causing grief with libifcore.dylib [but not libifcore.a] Such issues sometimes come up when linking to static libraries for creating a shared/dylib. > > > > BTW: I'm assuming you have sept 20 or newer petsc master branch. > > Yes. I have checked out your changes before testing. > > Out of curiosity: it looks like linking with -lpetsc is enough, so why use this very complicated link command? > i.e. this is enough to produce a perfectly fine binary: > mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc There is no [easy] automatic way of figuring out this reduced link command that might work. Satish

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Blaise A Bourdin 23 Sep '15

23 Sep '15

> On Sep 22, 2015, at 11:16 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > On Tue, 22 Sep 2015, Blaise A Bourdin wrote: > >> With the later configuration, it looks like what matters is the order in which -lmpifort and -lifcore are listed: >> This one works: >> mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lifcore -lmpifort >> >> This one does not: >> mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lmpifort -lifcore > > Does linking with -lifcore vs > /opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a > make a difference? It does. When I specify the path explicitly, the build works, regardless of the order in which libmpifort and libifcore are listed. > > And what do you have for: > > cd /opt/HPC/mpich-3.1.4-intel16.0/lib > ls > nm -Ao libmpiifort.* |grep get_command_argument This gives nothing at all: bourdin@galerkin:lib $ nm -Ao lib* |grep -i command bourdin@galerkin:lib $ > > BTW: I'm assuming you have sept 20 or newer petsc master branch. Yes. I have checked out your changes before testing. Out of curiosity: it looks like linking with -lpetsc is enough, so why use this very complicated link command? i.e. this is enough to produce a perfectly fine binary: mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Satish Balay 22 Sep '15

22 Sep '15

On Tue, 22 Sep 2015, Blaise A Bourdin wrote: > With the later configuration, it looks like what matters is the order in which -lmpifort and -lifcore are listed: > This one works: > mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lifcore -lmpifort > > This one does not: > mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lmpifort -lifcore Does linking with -lifcore vs /opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a make a difference? And what do you have for: cd /opt/HPC/mpich-3.1.4-intel16.0/lib ls nm -Ao libmpiifort.* |grep get_command_argument BTW: I'm assuming you have sept 20 or newer petsc master branch. Satish

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Blaise A Bourdin 22 Sep '15

22 Sep '15

On Sep 22, 2015, at 3:50 PM, Satish Balay <balay(a)mcs.anl.gov<mailto:[email protected]>> wrote: I'm not sure what to suggest. Blaise gets a successful build with: --with-cxx=0 --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a" The next thing Blaise could try is: --with-cxx=0 --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS=-lifcore This works. bourdin@galerkin:tutorials (master)$ otool -l ex5f90 |grep ifor name /opt/HPC/mpich-3.1.4-intel16.0/lib/libmpifort.12.dylib (offset 24) In contrast, with the build command suggested with richard, I get a non-functioning build: bourdin@galerkin:petsc-dev (master)$ ./configure --with-debugging=1 COPTFLAGS="-g -O0" FOPTFLAGS="-g -O0” CXXOPTFLAGS="-g -O0" --with-blas-lapack-dir=/opt/intel-16.0/compilers_and_libraries_2016/mac/mkl --with-mpi-dir=$MPI_HOME bourdin@galerkin:tutorials (master)$ otool -l ex5f90 |grep ifor name /opt/HPC/mpich-3.1.4-intel16.0/lib/libmpifort.12.dylib (offset 24) [and if this fails - see which ifcore the binary is using - via 'otool -l petscbinary |grep ifore'] If not - what I would do - is try compiling an example with a petsc makefile. [with the broken build] And then copy/paste the link line - removing stuff - until the binary created by that link line works. [and identify the linker option is making the difference]. Again - this would be for Blaise to try. With the later configuration, it looks like what matters is the order in which -lmpifort and -lifcore are listed: This one works: mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lifcore -lmpifort This one does not: mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -lmpifort -lifcore Same goes with the lengthy link line from the petsc makefile: mpif90 -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress -Wl,-commons,use_dylibs -Wl,-search_paths_first -g -O0 -I/opt/HPC/petsc-dev/include/petsc/finclude -o ex5f90 ex5f90.o -Wl,-rpath,/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -L/opt/HPC/petsc-dev/Darwin-intel16.0-g/lib -lpetsc -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016/mac/mkl -L/opt/intel-16.0/compilers_and_libraries_2016/mac/mkl -lmkl_intel -lmkl_sequential -lmkl_core -lpthread -lm -Wl,-rpath,/opt/X11/lib -L/opt/X11/lib -lX11 -lssl -lcrypto -Wl,-rpath,/opt/HPC/mpich-3.1.4-intel16.0/lib -L/opt/HPC/mpich-3.1.4-intel16.0/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -Wl,-rpath,/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin -lifcore -lmpifort -lifport -limf -lsvml -lipgo -lirc -lpthread -Wl,-rpath,/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin -lclang_rt.osx -limf -lsvml -lirng -lipgo -ldecimal -lirc -lclang_rt.osx -lmpicxx -limf -lsvml -lirng -lipgo -ldecimal -lirc -lclang_rt.osx -ldl -Wl,-rpath,/opt/HPC/mpich-3.1.4-intel16.0/lib -L/opt/HPC/mpich-3.1.4-intel16.0/lib -lmpi -lpmpi -Wl,-rpath,/opt/HPC/mpich-3.1.4-intel16.0/lib -L/opt/HPC/mpich-3.1.4-intel16.0/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -limf -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lsvml -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lirng -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lipgo -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -ldecimal -lc++ -lSystem -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -lirc -Wl,-rpath,/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin -lclang_rt.osx -Wl,-rpath,/opt/HPC/mpich-3.1.4-intel16.0/lib -L/opt/HPC/mpich-3.1.4-intel16.0/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/mkl/lib -Wl,-rpath,/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -L/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib -ldl this works, but switch the order of libmpifort and libifcore, and it does not anymore. (don’t ask me how I noticed!) Blaise Intel compilers (esp on Mac) had workarrounds to system issues encoded in the link command. [I remember the first generation of intel compilers on Mac had such issues]. And the way PETSc configure, and checkFortranLibraries() process/use this 'ifort -v' info can break these encoded workarrounds.. [Its a hacky piece of code - and not easy to get right] Ideally compilers should provide equivalent of 'mpicc -show' - so that configure tools can grab and use this info for language interoperable linking. [Jed suggested we should 'always use FC as linker' and not do any such detection. But then we still have to worry about C++. Previously we had machines where we had to use C++ linker - but perhaps such machines don't exist anymore] Satish On Tue, 22 Sep 2015, Richard Mills wrote: Blaise and Satish, I'm a bit slow to pick up on this thread as I was busy traveling, but since I use a Mac and work for Intel, I thought I should see if I could reproduce the problems that Blaise is seeing. I installed the 16.0 compilers and built a simple configuration ('--with-debugging=1 COPTFLAGS="-g -O0" FOPTFLAGS="-g -O0" CXXOPTFLAGS="-g -O0" --with-blas-lapack-dir=/opt/intel/compilers_and_libraries_2016/mac/mkl --with-mpi-dir=/Users/rtmills/packages/mpich-3.1.4-intel') using a very recent revision of 'master' (09b4d96fa5749f82a0af9a914729f77a4ef2b2fd, Sun Sep 20 22:51:31 2015 -0500). When I try running SNES ex5f and passing various command-line options, everything appears to work fine. Any suggestions for digging deeping into this to try to determine the difference between what Blaise and I are seeing? Best regards, Richard On Mon, Sep 21, 2015 at 10:21 AM, Blaise A Bourdin <bourdin(a)lsu.edu<mailto:[email protected]>> wrote: On Sep 20, 2015, at 9:04 AM, Satish Balay <balay(a)mcs.anl.gov<mailto:[email protected]>> wrote: Hm - I would suggest doing a minimal build build with: --with-cxx=0 --with-clib-autodetect=0 --with-fortranlib-autodetect=0 LIBS="/opt/intel-16.0/compilers_and_libraries_2016.0.083/mac/compiler/lib/libifcore.a" And see if that makes a difference. Satish, It does help. Turning off auto detect leads to a functional build, turning it back on leads to a non-functioning one. The configure.log without auto detect is here: https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/61967j4XaVp The one with auto detect there: https://filestogeaux.lsu.edu/public/download.php?FILE=bourdin/691pPOSRU The petscconf.h are attached -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

Re: [petsc-dev] broken options handling with intel 16.0 compilers on mac OS
by Jed Brown 22 Sep '15

22 Sep '15

Satish Balay <balay(a)mcs.anl.gov> writes: > And then the MPI c++ libraries.. The current MPI standard does not contain C++ bindings.

1 0