Fortran shared library for Python with use of OpenMP

[Petros]

Hello,

I have a problem while making a shared library in Fortran to be loaded from Python. I've put together a minimal example to show the problem.

The subroutine:

    subroutine sgesvf() bind(C, name="sgesvf")
    
    implicit none
    
    real*4 a(4,4), b(4), c(4,4)
    integer pivs(4), inf, n, i, j
    
    ! Externals from the LAPACK library
    external sgesv
    
    !     Initialize the matrix a and the vector b
    data a/ 1, 2, 3, 4, &
       6, 7, 9, 9, &
       11,12,19,14, &
       16,17,18,12/
    data b/ 1, 3, 5, 6/
    
    n=4
    !$OMP PARALLEL DO DEFAULT(NONE) &
    !$OMP SHARED(A,C,N) &
    !$OMP PRIVATE(I,J) &
    !$OMP SCHEDULE(DYNAMIC,1)
    do i = 2, n
      do j = 1, i
         c(j,i) = ( a(j,i) + a(j,i-1) ) / 2.0
      end do
    end do
    
    !     Compute the solution
    call sgesv(4, 1, a, 4, pivs, b, 4, inf)
    
    !     Figure out if sgesv found a solution or not
    if (inf .eq. 0) then
       write (*,*) 'successful solution'
    else if (inf .lt. 0) then
       write (*,*) 'illegal value at: %d', -inf
       stop
    else if (inf .gt. 0) then
       write (*,*) 'matrix was singular'
       stop
    else
       write (*,*) 'unknown result (can''t happen!)'
       stop
    end if
    
    write(*,*) 'pivs=', pivs
    
    end subroutine sgesvf

which tests the most important tools I use in my real code, that is OpenMP and Lapack/Blas.

If I compile ignoring the OpenMP directives, that is:

    ifort -O2 -warn all -fPIC -I/opt/intel/mkl/include -module Release/ -c main.f90 -o Release/main.o
    ifort -shared  Release/main.o -o Release/libshared_lib_for_python_example.so -L/opt/intel/lib/intel64 -lmkl_rt -lpthread -lm

and use as:

    from ctypes import cdll
    lib = cdll.LoadLibrary('libshared_lib_for_python_example.so')
    print lib.sgesvf()

I get:

    successful solution
    pivs=           4           4           3           4           0

If I include the OpenMP:

    ifort -O2 -warn all -fPIC -openmp -I/opt/intel/mkl/include -module Release/ -c main.f90 -o Release/main.o
    ifort -shared  Release/main.o -o Release/libshared_lib_for_python_example.so -L/opt/intel/lib/intel64 -openmp -lmkl_rt -lpthread -lm

I get:

    Traceback (most recent call last):
      File "test.py", line 16, in <module>
        lib = cdll.LoadLibrary('libshared_lib_for_python_example.so')
      File "/usr/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
        return self._dlltype(name)
      File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
        self._handle = _dlopen(self._name, mode)
    OSError: /opt/intel/composer_xe_2013_sp1.2.144/ipp/../compiler/lib/intel64/libifcoremt.so.5: undefined symbol: _intel_fast_memmove

I've tried several variations I found on forums (like adding -lifport -lifcoremt -lifcore -lsvml -lirc to the linking, make sure I'm linking with the right libraries, etc.). I've also tried posting on Intel forum since 2 weeks without any result.

I work under Debian Linux 7.0. My Intel compiler is: Version 14.0.2.144 Build 20140120.

Thanks in advance

[Petros]

EDIT:

As soon as I posted this, I think I found the problem. If I statically link with:

-Wl,--start-group  /opt/intel/mkl/lib/intel64/libmkl_intel_lp64.a /opt/intel/mkl/lib/intel64/libmkl_sequential.a /opt/intel/mkl/lib/intel64/libmkl_core.a /opt/intel/lib/intel64/libirc.a /opt/intel/lib/intel64/libimf.a -Wl,--end-group -L/opt/intel/lib/intel64 -liomp5 -lpthread -lm

The problem disapears. Everything seems to be running OK. libirc and libimf were needed, otherwise I was getting an error: 

undefined symbol: _intel_fast_memmove

Thanks anyway,

Petros

[TimP]

I think you have lost important parts of this post.

MKL link advisor: http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor

shows how the start-group....end-group linker directives must be used when linking functions from static MKL libraries.  The MKL libraries would include dependencies on additional libraries provided with Intel compilers.  

You might note the cautions given elsewhere about including an unnecessary -lm in such a way that it might result in an unpredictable mixture of math functions from your OS library displacing similar functions from the Intel libraries.