- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have an application that I last built and executed using Intel Fortran 16 on CentOs 6 a few years ago. I am now trying to build with Intel Fortran 20, update 1, on CentOS 7.
When linking an object file with an ar library, both of which I rebuilt with ifort 20, I get the following message:
ld: /path_to/intel/compilers_and_libraries_2020.1.217/linux/bin/intel64/../../lib/LLVMgold.so: error loading plugin: libimf.so: cannot open shared object file: No such file or directory
Neither .so file is familiar to me. Could someone help me get started debugging this issue?
Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is some more information. I have one instance of LLVMgold.so
./intel/compilers_and_libraries_2020.1.217/linux/lib/LLVMgold.so
There are several instances of libimf.so
./intel/itac/2020.1.024/intel64/bin/rtlib/libimf.so
./intel/compilers_and_libraries_2020.1.217/linux/compiler/lib/ia32_lin/libimf.so
./intel/compilers_and_libraries_2020.1.217/linux/compiler/lib/intel64_lin/libimf.so
./intel/intelpython3/pkgs/icc_rt-2020.1-intel_217/lib/libimf.so
./intel/intelpython3/lib/libimf.so
I investigated whether this had anything to do with LD_LIBRARY_PATH. It was not set when I first tried the link. I then tried setting it.
> echo $LD_LIBRARY_PATH
~/intel/compilers_and_libraries_2020.1.217/linux/compiler/lib/intel64_lin/libimf.so
Same result:
ld: /path_to/intel/compilers_and_libraries_2020.1.217/linux/bin/intel64/../../lib/LLVMgold.so: error loading plugin: libimf.so: cannot open shared object file: No such file or directory
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm a bit confused about the prefix for all those paths - you have "/path_to", the current directory and perhaps the shell metachar for the current users home directory.
Linux is not my forte, and I don't have an ifort compiler installation on linux to check, so the value of the following is all a bit questionable, but LD_LIBRARY_PATH should be a list of directories, not a filename, and that list of directories should not have a literal "~" in it (that character should have been expanded when the environment variable was defined).
Are you linking in a shell that has been set up with ifortvars.sh?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your assistance.
/path_to is just a way to refer to my home directory; I was once told that it is not a good idea (for security reasons) to include that in posts.
I did try to set LD_LIBRARY_PATH with the path itself; sorry that my post contained an earlier incorrect usage. Using the path did not eliminate the error, however.
Online, I did see a comment about setting up with ifortvars.sh but did not know what needs to be done. I never did that when I was using ifort versions 14 through 18 in past years. Is it simply a matter of executing the shell script? Should that be done from my .bashrc? Are there environment variables that I can check to ensure that the set-up was successful?
Best regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's always been required to "source" ifortvars.sh. Typically this is done as:
source /opt/intel/bin ifortvars.sh
If you didn't do this, where did the compiler find its path to run?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, Steve. I don't recall ever doing this, but I could be mistaken.
Very good to say hello again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
. . . and running ifortvars.sh with the correct arguments does the trick. Thanks!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page