Symbol missing in libifport.so

[gib]

Hello,

I am building a program with intel/2017a that I used to build with intel/2015a, the difference is that now I am linking libmkl.so instead of libblas.so and liblapack.so.

The program builds, but I get an error when I execute it:

monolayer_m_main: symbol lookup error: /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libifport.so.5: undefined symbol: for_ifcore_version

This is on a Cray (the previous build with intel/2015a was on the cluster that the Cray has replaced).  I have sent the same message to the tech support on this system.

Any suggestions?

Thanks

Gib

[Steve_Lionel]

That's a very interesting path for libifport.so. It seems unlikely to be the one installed along with the compiler and is probably one from an older version.

[gib]

Thanks Steve.  I'll pass that comment on to the system maintainers.

Gib

[gib]

Steve, two things make this very puzzling.

I have another program that used libmkl.so, and it runs without an error.

The tech support guy has not responded to your comment about the possibility that the libifport.so found is an old version, but he has found that he can run my program (after loading the same module, intel/2017a) without the error.  We have the same paths in LD_LIBRARY_PATH.  It is very odd.

This is what >ldd monolayer_m_main yields:

    linux-vdso.so.1 =>  (0x00002aaaaaaab000)
    libmonolayer_m.so => /nesi/project/uoa00014/monolayer_m-abm/build/libmonolayer_m.so (0x00002aaaaaaaf000)
    libmkl_intel_lp64.so => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/mkl/lib/intel64/libmkl_intel_lp64.so (0x00002aaaaae80000)
    libmkl_intel_thread.so => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/mkl/lib/intel64/libmkl_intel_thread.so (0x00002aaaab919000)
    libmkl_core.so => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/mkl/lib/intel64/libmkl_core.so (0x00002aaaad9f5000)
    libm.so.6 => /lib64/libm.so.6 (0x00002aaaafb41000)
    libiomp5.so => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libiomp5.so (0x00002aaaafe43000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaab01e8000)
    libc.so.6 => /lib64/libc.so.6 (0x00002aaab0404000)
    libgcc_s.so.1 => /opt/nesi/mahuika/GCCcore/5.4.0/lib64/libgcc_s.so.1 (0x00002aaab07c7000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002aaab07df000)
    libifport.so.5 => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libifport.so.5 (0x00002aaab09e3000)
    libifcoremt.so.5 => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libifcoremt.so.5 (0x00002aaab0c12000)
    libimf.so => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libimf.so (0x00002aaab0fa3000)
    libsvml.so => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libsvml.so (0x00002aaab1490000)
    libintlc.so.5 => /opt/nesi/mahuika/imkl/2017.6.256-iimpi-2017a/lib/intel64/libintlc.so.5 (0x00002aaab23ae000)
    /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

[Lorri_M_Intel]

Let me tell you what I know, and we'll see if that helps.  I'm more of a Windows person than a Linux person, so some of the "finding .so files" is magic to me.

for_ifcore_version is actually defined in libifcoremt even though it's referenced by libifport.

Is it possible that in your environment, as opposed to your colleague's environment, that a 2015 libifcoremt is somehow being pulled in?  

(If this were Windows, I'd ask about your PATH; I don't know if that affects finding .so files like it does finding .dll files)

                          Hope this gives a clue --

                                               --Lorri

[Juergen_R_R]

The Linux equivalent is LD_LIBRARY_PATH. Gib, can you do 

ldd  <your_executable>

to see which libraries are actually loaded for the binary.

For me this looks e.g. like this:

$ ldd whizard
	linux-vdso.so.1 =>  (0x00007ffef3cfb000)
	libvamp.so.0 => /data2/reuter/local/whizard/trunk/_build_ifort17/vamp/src/.libs/libvamp.so.0 (0x00007f6d0201d000)
	libcirce1.so.0 => /data2/reuter/local/whizard/trunk/_build_ifort17/circe1/src/.libs/libcirce1.so.0 (0x00007f6d01df4000)
	libcirce2.so.0 => /data2/reuter/local/whizard/trunk/_build_ifort17/circe2/src/.libs/libcirce2.so.0 (0x00007f6d01be7000)
	libLHAPDF.so => /data2/reuter/local/lib/libLHAPDF.so (0x00007f6d0190a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6d01601000)
	libfastjet.so.0 => /data2/reuter/local/lib/libfastjet.so.0 (0x00007f6d0136d000)
	libfastjetplugins.so.0 => /data2/reuter/local/lib/libfastjetplugins.so.0 (0x00007f6d0112d000)
	libsiscone_spherical.so.0 => /data2/reuter/local/lib/libsiscone_spherical.so.0 (0x00007f6d00f0d000)
	libsiscone.so.0 => /data2/reuter/local/lib/libsiscone.so.0 (0x00007f6d00ceb000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6d00ae7000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6d008d0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d00506000)
	libpythia8.so => /data2/reuter/local/lib/libpythia8.so (0x00007f6cffd39000)
	libifport.so.5 => /opt/intel/2018/lib/intel64_lin/libifport.so.5 (0x00007f6cffb0d000)
	libifcoremt.so.5 => /opt/intel/2018/lib/intel64_lin/libifcoremt.so.5 (0x00007f6cff779000)
	libimf.so => /opt/intel/2018/lib/intel64_lin/libimf.so (0x00007f6cff1e6000)
	libsvml.so => /opt/intel/2018/lib/intel64_lin/libsvml.so (0x00007f6cfd8d8000)
	libintlc.so.5 => /opt/intel/2018/lib/intel64_lin/libintlc.so.5 (0x00007f6cfd66a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6cfd44d000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6cfd0c5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6d08f17000)

Or could it be that you link in some external library that was compiled with a different version of ifort?

[gib]

Juergen: see above ;)

Yes, it is very possible that I link in a library that was compiled with a different version of ifort.  But this doesn't explain why my other program, which uses the same libraries, runs OK, and nor does it explain why the tech support person can run this program without error.

Cheers, Gib

[gib]

Hi Lorri, thanks for your suggestion.  As Juergen pointed out, Linux has PATH for executables, and LD_LIBRARY_PATH for libraries.  When the tech support guy runs my program successfully, he is using my LD_LIBRARY_PATH - to be precise, he adds to his default LD_LIBRARY_PATH the path to monolayer_m_main.so, which is what I do.  It is still possible that there is something different in his environment, in fact you could say there MUST be something different, but he can't see it.

Unfortunately, because of the 2 factor authentication they have put in place, he can't log on as me.

Gib

[Juergen_R_R]

gib wrote:

Juergen: see above ;)

Yes, it is very possible that I link in a library that was compiled with a different version of ifort.  But this doesn't explain why my other program, which uses the same libraries, runs OK, and nor does it explain why the tech support person can run this program without error.

Cheers, Gib

Sorry, overlooked this, could you do the same for

libmonolayer_m.so => /nesi/project/uoa00014/monolayer_m-abm/build/libmonolayer_m.so (0x00002aaaaaaaf000)

to see whether it doesn't get pulled in via this library.

[gib]

I have a solution, but not a complete explanation.

On checking my CMakeLists.txt I discovered that I was linking (static) libraries that are not needed.  These are in fact libraries that were built some time ago, from a mixture of C and Fortran, i.e. with a different version of ifort (and icc).  When I remove these unneeded libraries from the build, the error goes away.

These libraries are being used in the other program, which doesn't give an error.  It is as if an error results from linking unused libraries, which is surprising to me.