error - libifcoremt.so.5 undefined symbol: __intel_sse2_strcpy

error - libifcoremt.so.5 undefined symbol: __intel_sse2_strcpy

Ritratto di coolweather

Hello,

I compile with ifort and icc 13.0.1 20121010

the compilation options are

# R paths
RDIR = R/R-2.15.2
RLIBDIR = $(RDIR)/lib64/R/lib
RINCDIR = $(RDIR)/lib64/R/include

# intel paths
ILIBDIR = /opt/intel/lib/intel64

# files
OBJ = x.o y.o z.o f1.o f2.o c.o

# compilators
FORT = ifort
CC = icc

# compilation flags
FFLAG = -c -fPIC
CFLAG = -c -fPIC

# optimization flags
FORT_OPTIMIZATION = -fast -threads -parallel -openmp -fbuiltin -fltconsistency -nowarn -opt-matmul -static-intel -m64 -mkl=parallel
CC_OPTIMIZATION = -O3 -ipo -parallel -openmp -fbuiltin -static -opt-matmul -xHost -m64 -mkl=parallel

all:
$(FORT) $(FFLAG) $(FORT_OPTIMIZATION) x.f90
$(FORT) $(FFLAG) $(FORT_OPTIMIZATION) f1.f f2.f
$(FORT) $(FFLAG) $(FORT_OPTIMIZATION) -heap-arrays z.f90
$(CC) $(CFLAG) $(CC_OPTIMIZATION) -I$(RINCDIR) c.c
$(FORT) -o libname.so -shared $(OBJ) -L$(RLIBDIR) -lR -L$(ILIBDIR) -lifport -lifcoremt -liomp5 -lpthread
rm -f *.o *.mod

 when loading libname.so dynamic library in R I have the following errors
-- unable to load shared library 'libname.so':
/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/libifcoremt.so.5: undefined symbol: __intel_sse2_strcpy
(other errors : __intel_ssse3_memcpy, __intel_sse2_strcpy) 

when I try to link libifcoremt statically it produce also en error asking to recompile libifcoremt.a with -fPIC option

please tell me how to compile my project in multithreading openmp mkl mode with static and dynamic linking ?

thank you
 

15 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

I suppose you may have to postpone linking the compiler and system libraries until final link, leaving them out of your .so.

When you do reach final link stage, it may be better to use -openmp or -parallel to add those libraries.  Depending on linux version etc. not all of them may be supported for static link.

Ritratto di coolweather

could you give me more detailed explanation with compilier/linker options example please ?

the solution to link all external intel libraries statically in a one final *.so will ok for me too, but I had linked errors too.

linux is RH5

you mean that I can not use -parallel and -openmp at the same time is not it ?

I would be very greatful if you could explan me how to compile and link the following construction into one *.so file, please ?

- several .f files of F77 subroutines
- several .f90 files of F90 subroutines, some of them calls mkl library functions
- one .f90 subroutine with bind(c) option 
- one .c function with R.h include that calls the last f90 bind(c) subroutine (the function is similar to http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Calling-_002eCall)

- multithreaded execution of .so is needed

thank you so much for your help !

Ritratto di coolweather

please, could you give me the right compiler and linker options for my case ?

-parallel and -openmp should work together; OpenMP parallel regions should exclude the effect of -parallel.  Either or both have the same effect at link time, equivalent to -liomp5 -lpthread.

I would suggest omitting -lifport -lifcoremt -liomp5 -lpthread from the command which builds your .so

and performing the final link which includes your .so with ifort -openmp or -parallel, with or (simpler) without static options.

As you didn't show how you are using your .so I don't think we can be more specific.

Ritratto di coolweather

thank you for your message, I'm a little bit perturbed on using compiler options.

do you mean that

ifort -c -fpic -parallel -openmp -threads *.f90
ifort -o my.so *.o 

and

ifort -c -fpic *.f90
ifort -o my.so *.o -lptheads -liomp5

are the same things ?

or do you mean that if one sets options -openmp -parallel -threads ifort automatically links to the necessary libraries (pthreads. iomp5...) ?

if I link mkl, is it sufficient to add -mkl option like ifort -c -fpic -mkl *f.90
or I have to link the libraries too like ifort -o my.so -lmkl ....? 

if I use bind(c) iso standards for mixed C/Fortran programming, what library I have to link in addition ?

I use my.so by following way :

in R command line :
dyn.load("my.so")
is.loaded("myfunction_c")
results <- .Call("myfunction_c", params)
dyn.unload("my.so")

myfunction_c parses params (list of SEXP variables) and transforms them into double* int* vectors 
these vectors passed into fortran bind(c) subroutine called as external function from C program.
Further the fortran subroutine calls many different maths including mkl.

No, I'll say it once more.

The effect of either -parallel or -openmp in the link step (no -c) is to add -liomp5 -lpthread ..., using the library directory path you set up for ifort.  Please check it yourself.  In order to help avoid confusion, the compiler is designed so the same options you used when making .o files (the -c step) can be used in the link step to get the corresponding libraries.

Yes, you do need -fpic when making .o files which are to be built into a .so.  That option isn't implied by any other.

-threads is not a relevant option for ifort.

The -mkl option makes a default selection of MKL libraries, good for the most common case with ifort or icc.  If you want options such as ilp64, static MKL link, or stubbing out OpenMP (mkl_serial), you must follow the MKL link advisor.

bind(c) in itself doesn't involve any libraries or USE files, unless the C functions are in a library not included automatically by ifort.

OK, there's always a possibility more of us may get involved with R calling Fortran compiled functions.  I suppose, as long as you have the LD_LIBRARY_PATH set according to the compiler setup to include the path to the compiler .so libraries, the dependencies of the .so you load for R should be satisfied "dynamically." 

These libraries are available in a redistributable package so you can run where you don't have a compiler installation, without having to solve those static link problems.

Ritratto di coolweather

thank you, it is much more clear with compiler-linker options (-openmp, parallel)

about -threads option I read from here http://software.intel.com/sites/products/documentation/doclib/stdxe/2013...
I guessed that this option is to compile for multithreading and link to -lifcoremt.so library, is not it ?

thank you for MKL link advisor ! very practical and useful tool 

perhaps, to avoid the problems of dynamic load of libraries, it is better to link all intel libraries statically to my .so file ?

could you tell me the right options for static linking please ?
when I tryed to do a static linking, I had an error of intel *.a libraries were not compiled with -fpic option 

thank you!

libifcoremt.so should be linked automatically with the other build options you are using.

This has been my concern, that you may not be able to link all necessary libraries statically into the .so you build, as the original message about no -fpic in .a indicated, among other things.  So you may need to rely on your .so picking up some or all of those other .so from your compiler library and linux installation.  The option -static-intel will set a preference for static link from the compiler library; you should not need to static link linux libraries like pthread.

Ritratto di coolweather

here is the error I have using -static-intel option

ld: /opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/libifcoremt.a(for_close.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/libifcoremt.a: could not read symbols: Bad value
make: *** [all] Error 1

 is it possible to avoid this error in order to have a static linking of intel libs ?

when compiling without -static-intel the error is 

> dyn.load("libgs3R.so")
Error in dyn.load("libgs3R.so") :
unable to load shared library '/data/vifeoktistov/gs3R/test/libgs3R.so':
/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/libifcoremt.so.5: undefined symbol: __intel_sse2_strcpy

 so the problem is in the both cases with 'libifcoremt' library

Ritratto di coolweather

for the moment I found the following solution 
 

# compilation flags
FFLAG = -c -fPIC -static-intel -O3 -xhost -ipo -parallel -openmp -fbuiltin -fltconsistency -opt-matmul -nowarn
CFLAG = -c -fPIC -static-intel -O3 -xhost -ipo -parallel -openmp
# linker flags
LINKER_FLAGS = -O3 -xhost -fPIC -static-intel -parallel -openmp -threads -shared $(OBJ) -Wl,--start-group $(ILIBDIR)/libifcoremt_pic.a -Wl,--end-group -Bstatic -lirc -L$(RLIBDIR) -Bdynamic -lR -lm -liomp5

could you verify the options please ? I would like to obtain extreme optimization on my host machine.

now I can load successfully in R this compiled library .so
dyn.load("my.so")
but the program executed in one thread !

how to make multithread execution ? I add -parallel -openmp and -threads options, but it is still one thread !

thank you for your aid ! 

I'd be surprised if the start-group....end-group bracketing a single library were needed, but it shouldn't have any bad effect.  It's required for static linking with MKL.  You have  -l specifications which ought to be redundant ( -lm -liomp5).

I suppose

ldd libgs3R.so

should show which .so libraries remain as dependencies.

As to not seeing multi-threaded execution, you should look into where the time is spent, and add a -opt-report option to see whether the optimizations you hoped for are applied to the time-consuming loops. -opt-matmul will parallelize only Fortran MATMUL intrinsics on matrices over some size threshold.  -openmp will parallelize only loops where you set up omp parallel regions, while -parallel will search other loops for opportunities to apply implicit OpenMP.  By putting an aggressive setting of -par-threshold, you may see additional parallel execution but not necessarily with a performance gain.

Ritratto di coolweather

here you can find the dependencies of my.so

$ ldd libmy.so
linux-vdso.so.1 => (0x00007fffc3583000)
libR.so => /usr/lib64/R/lib/libR.so (0x00002b9ad00f1000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b9ad06d8000)
libiomp5.so => /opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/libiomp5.so (0x00002b9ad08f4000)
libm.so.6 => /lib64/libm.so.6 (0x00002b9ad0bf7000)
libc.so.6 => /lib64/libc.so.6 (0x00002b9ad0e7a000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a21800000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b9ad11d3000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b9ad13e2000)
libRblas.so => /usr/lib64/R/lib/libRblas.so (0x00002b9ad15e6000)
libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002b9ad1811000)
libreadline.so.5 => /usr/lib64/libreadline.so.5 (0x00002b9ad1aa9000)
libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x00002b9ad1ce6000)
libz.so.1 => /lib64/libz.so.1 (0x00002b9ad1f43000)
librt.so.1 => /lib64/librt.so.1 (0x00002b9ad2158000)
libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00002b9ad2361000)

I tried different combinations of options but it stays always one threaded, and I don't understand why.
 

You should avoid linking libgomp along with libiomp5, as libiomp5 is intended to support all libgomp calls compatibly, and you need a single instance of OpenMP to manage all OpenMP thread pools. 

Mixing gfortran and ifort is unsafe since the run-time libraries aren't compatible.  Perhaps your static linking of ifort libraries has compensated, but the mixture isn't supported.  It would be better to find all the Fortran and build it with the one compiler (ifort).

Ritratto di coolweather

my project is completly ifort compiled, you can see the flags above.
I use C wrap to call a fortran subroutine just for compatibility with R, only for parsing R (SEXP) objects to int, double vectors.
the C part is also compiled with icc.
the only external link is R.so (R dynamic library)
in my linker flags I linked it to the intel compilation (ifort, icc) of R, compiled with using MKL BLAS multitread option.

I really do not know why I obtained such a mixture

is there the option of linker/compiler that force to link to the concrete .so library ?
as 'ldd my.so' shows in linker options I set the reference to intel compiled R, but linker has made link to a commont gfort et gcc compiled R.so
I guess that from here there are other files as libgomp, ... 

Accedere per lasciare un commento.