- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve. I'll pass that comment on to the system maintainers.
Gib
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page