[petsc-dev] broken options handling with intel 16.0 compilers on mac OS

Satish Balay balay at mcs.anl.gov
Wed Sep 23 10:45:31 CDT 2015


On Wed, 23 Sep 2015, Blaise A Bourdin wrote:

> 
> > On Sep 22, 2015, at 11:16 PM, Satish Balay <balay at 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 at galerkin:lib $ nm -Ao lib* |grep -i command
> bourdin at 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



More information about the petsc-dev mailing list