Community
cancel
Showing results for 
Search instead for 
Did you mean: 
selmilab
Beginner
105 Views

Unresolved OpenMP references and static linking

Hello, since updating to ICC 14.0.3 I'm having a warning apper whenever I want to statically link my application.

The warning reads as:

ipo: warning #11021: unresolved omp_set_num_threads
        Referenced in /tmp/ipo_icc10sv2U.o
ipo: warning #11021: unresolved omp_get_thread_num
        Referenced in /tmp/ipo_icc10sv2U.o
        Referenced in libmkl_intel_thread.a(dlaset_par.o)
        Referenced in libmkl_intel_thread.a(dlange_par.o)
        Referenced in libmkl_intel_thread.a(dormlq_par.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_par.o)
        Referenced in libmkl_intel_thread.a(dlacpy_par.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_offload_par.o)
        Referenced in libmkl_intel_thread.a(dormqr_par.o)
        Referenced in libmkl_intel_thread.a(dtrsm_drv.o)
        Referenced in libmkl_intel_thread.a(domatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(dgelqf_pf_par.o)
        Referenced in libmkl_intel_thread.a(dgemm_drv.o)
        Referenced in libmkl_intel_thread.a(dtrmm_drv.o)
        Referenced in libmkl_intel_thread.a(somatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(comatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(zomatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(simatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(dimatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(cimatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(zimatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_pf_par.o)
        Referenced in libmkl_intel_thread.a(dgemv_omp.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_pfnr_par.o)
        Referenced in libmkl_intel_thread.a(daxpy_omp.o)
ipo: warning #11021: unresolved omp_set_nested
        Referenced in /tmp/ipo_icc10sv2U.o
ipo: warning #11021: unresolved omp_get_num_threads
        Referenced in libmkl_intel_thread.a(dlaset_par.o)
        Referenced in libmkl_intel_thread.a(dlange_par.o)
        Referenced in libmkl_intel_thread.a(dormlq_par.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_par.o)
        Referenced in libmkl_intel_thread.a(dlacpy_par.o)
        Referenced in libmkl_intel_thread.a(dormqr_par.o)
        Referenced in libmkl_intel_thread.a(dtrsm_drv.o)
        Referenced in libmkl_intel_thread.a(domatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(dgelqf_pf_par.o)
        Referenced in libmkl_intel_thread.a(dgemm_drv.o)
        Referenced in libmkl_intel_thread.a(dtrmm_drv.o)
        Referenced in libmkl_intel_thread.a(somatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(comatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(zomatcopy2_par_omp.o)
        Referenced in libmkl_intel_thread.a(simatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(dimatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(cimatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(zimatcopy_par_omp.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_pf_par.o)
        Referenced in libmkl_intel_thread.a(dgemv_omp.o)
        Referenced in libmkl_intel_thread.a(dgeqrf_pfnr_par.o)
        Referenced in libmkl_intel_thread.a(daxpy_omp.o)
ipo: warning #11021: unresolved omp_in_parallel
        Referenced in libmkl_intel_thread.a(mkl_threading.o)
ipo: warning #11021: unresolved omp_get_max_threads
        Referenced in libmkl_intel_thread.a(mkl_threading.o)
ipo: warning #11021: unresolved omp_get_num_procs
        Referenced in libmkl_intel_thread.a(mkl_threading.o)
/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64/libmkl_core.a(mkl_aa_fw_load_orsl_lite_lib.o): In function `mkl_aa_fw_load_orsl_lite_lib':
../../../../serv/offload/framework/core/mkl_aa_fw_load_orsl_lite_lib.c:(.text+0xbe): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

 

Link line is:

icc -o out <bunch of object files>  -L. -g -openmp -mkl=parallel -parallel  -L/opt/intel/vtune_amplifier_xe_2013/lib64 -littnotify -static -fast -openmp   -lpthread -Wl,--start-group /opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64/libiomp5.a /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.a /opt/intel/mkl/lib/intel64/libmkl_core.a /opt/intel/mkl/lib/intel64/libmkl_intel_thread.a -Wl,--end-group -lgfortran -lm

Any toughts?

0 Kudos
7 Replies
TimP
Black Belt
105 Views

Recent icc and MKL don't support static linkage of libiomp5.

Your link command is rather unusual.  I don't see any reason for linking libgfortran unless you have included objects built by libgfortran.

You need to assure that -openmp or -parallel is processed by icc before the linker script is generated, e.g. by making it one of the first options.  If one of those options is processed, your own -lpthread -lm will be redundant. If you don't want to use -openmp or -parallel, you will need -liomp5 in the usual manner recommended by MKL link advisor.

I don't know the consequences of specifying both a -mkl option for dynamic linkage and the specific MKL library references for static linkage; I would suggest choosing one or the other.

You can view what icc puts in the link command by adding -# option early enough in the string for icc to see it.

selmilab
Beginner
105 Views

Tim Prince wrote:

Recent icc and MKL don't support static linkage of libiomp5.

Really? This could be bad. I really need to generate static executables. But if this is not supported, what's the point of providing libiomp5.a?

Your link command is rather unusual.

Why?

I don't see any reason for linking libgfortran unless you have included objects built by libgfortran.

You are right, it was a legacy leftover

You need to assure that -openmp or -parallel is processed by icc before the linker script is generated, e.g. by making it one of the first options.  If one of those options is processed, your own -lpthread -lm will be redundant. If you don't want to use -openmp or -parallel, you will need -liomp5 in the usual manner recommended by MKL link advisor.

I've changed the link line to:

icc -o out <bunch of object files>  -L. -g -parallel -ipo -static   -lpthread -lm -lcsparse_icc  -Wl,--start-group /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.a /opt/intel/mkl/lib/intel64/libmkl_core.a /opt/intel/mkl/lib/intel64/libmkl_intel_thread.a -Wl,--end-group

-lpthread and -lm are there because mkl link advisor told me so

TimP
Black Belt
105 Views

icc -openmp implies -liomp5 -lpthread.  If you omit -openmp and -parallel you will require -lpthread.

selmilab
Beginner
105 Views

Ok, thank you, but the issue is not the link command. The issue is how to deal with those unresolved references

pbkenned1
Employee
105 Views

Those 'unresolved references' are just warnings, you should still have been able to produce an executable.  Calls to static versions of omp_get/set_num_threads() can still be resolved from libiomp5.a in the 14.0.3 compiler, but they are not usable with -ipo.  I'll ask the developers if that's by design (I suspect so).

We strongly discourage static linkage of the OpenMP runtime, and in some future version of the compiler we will remove libiomp5.a completely from our Linux libraries (that's already happened on Windows).  In general, the Linux community is moving away from static linking.

Note also you were previously using -fast, which implies -ipo. 

 

Patrick

selmilab
Beginner
105 Views

Patrick Kennedy (Intel) wrote:

We strongly discourage static linkage of the OpenMP runtime, and in some future version of the compiler we will remove libiomp5.a completely from our Linux libraries (that's already happened on Windows).  In general, the Linux community is moving away from static linking.

What if I want to distribute the executable without the burden of distributing all the needed libraries?

TimP
Black Belt
105 Views

According to the recommendations to which Patrick referred, you could link all static Intel compiler libraries except for libiomp5 by specifying -static-intel.  The  MKL link setup you quoted also uses static libraries explicitly,  So you should need to distribute only the libiomp5.so along with your application.  You would add the libiomp5.a with full path as you did for MKL (after the MKL group), if you wished to over-ride that part of the recommendation.

The -static option to link all possible static libraries including those provided by linux may be over-kill, as you can expect any linux installation of the same or newer glibc version to work with dynamic link, and the -static option doesn't guarantee compatibility with older glibc.