libifcore.so.5: undefined symbol: _intel_fast_memmove

Sourish_B_ · ‎09-01-2015

Hello,

I routinely use f2py to compile fortran code into python modules. Recently, I have run across a baffling problem. I compiled a module using the following command line:

f2py --compiler=intelem --fcompiler=intelem -c interpol_grid.pyf interpol_grid.F90

which produced the file interpo.so, as it was supposed to. However, when I tried loading it from within ipython, I got

$ ipython
Python 2.7.9 (default, Mar  9 2015, 11:04:54) 
Type "copyright", "credits" or "license" for more information.

IPython 3.0.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import interpol
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-87b1fd1906de> in <module>()
----> 1 import interpol

ImportError: /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libifcore.so.5: undefined symbol: _intel_fast_memmove

I checked that interpol.so does indeed link to libifcore.so,

$ ldd interpol.so 
        linux-vdso.so.1 =>  (0x00007fff5def6000)
        libpython2.7.so.1.0 => /hpc/sw/python-2.7.9/lib/libpython2.7.so.1.0 (0x00002b7800509000)
        libifport.so.5 => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libifport.so.5 (0x00002b78008eb000)
        libifcore.so.5 => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libifcore.so.5 (0x00002b7800b19000)
        libimf.so => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libimf.so (0x00002b7800e4f000)
        libsvml.so => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libsvml.so (0x00002b7801309000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b7801f75000)
        libintlc.so.5 => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libintlc.so.5 (0x00002b78021fa000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b7802454000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b7802671000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b7802a06000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b7802c1c000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00002b7802e20000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b78000dd000)

and the libifcore.so.5 in question links to libintlc.so.5,

$ ldd /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libifcore.so.5
        linux-vdso.so.1 =>  (0x00002b4bcffa5000)
        libimf.so => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libimf.so (0x00002b4bd04df000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b4bd09b6000)
        libintlc.so.5 => /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libintlc.so.5 (0x00002b4bd0c3a000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b4bd0e95000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b4bcff85000)

which contains the symbol _intel_fast_memmove,

$ nm /opt/intel/composer_xe_2015.0.090/compiler/lib/intel64/libintlc.so.5  | grep intel_fast_memmove
000000000000e160 T _intel_fast_memmove
000000000000e130 T _intel_fast_memmove.A
000000000000e140 T _intel_fast_memmove.M
000000000000e150 T _intel_fast_memmove.P

So then why does ipython's import fail with the message that libifcore.so.5 can't find _intel_fast_memmove?

Any help is appreciated,

Sourish

Kevin_D_Intel · ‎09-02-2015

I don’t know what is leading to this. One thing lurking in the back of my mind is a change to ld to no longer follow the "DT_NEEDED" tags in the .so's, but that's not a recent change and may not be at play here at all it just "felt" related. (https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking and https://wiki.debian.org/ToolChain/DSOLinking)

I wondering whether as a work around specifying one or the other of -intel-static or -lintlc might avoid the issue but don’t know the suggested syntax for feeding those to f2py. You may not desire the first option to use static libs due to bloating your resulting .so some. The second option might help force a direct link to the missing library within your .so and preserve the use of other shared libs.

Did you recently upgrade your Intel compiler?
What version of Linux are you using?

I could try replicating and investigating further as time permits if you can share some pointers with me about obtaining/recreating your f2py/Python 2.9/IPython 3.0 setup.

Sourish_B_ · ‎09-03-2015

Hi Kevin,

Thanks for the response. I did try explicit -lintlc, but that didn't solve the problem. Today one of the admins on our system figured it out. Basically, I was compiling my module using ifort 15.0, but there was another module in my python profile which had been compiled with ifort 13.0. This python module compiled with ifort 13.0 -- which was still inked to 13.0 libraries -- was being loaded first, by default. When I then tried loading the module compiled with ifort 15.0, I got the error I reported.

I don't know what the error means, but recompiling the older module with ifort 15.0 solved the problem.

Cheers,

Sourish

Kevin_D_Intel · ‎09-06-2015

Thank you for following up. That routine did not exist in the 13.x compiler/lib hence the error. Glad to hear this was resolved.