- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greetings,
I have some code which I compiled like this on my host:
$ ifort -openmp -mmic -o test.phi test.f90 -O4
I copied it up to the mic and tried to run
mic0$ ./test.phi
./test.phi: error while loading shared libraries: libiomp5.so: cannot open shared object file: No such file or directory
Oh! I read about this in the docuentation, the library path is missing. Simple fix, right? I NFS mount the /opt/intel up to the mic so it should go smoothly.
mic0$ source /opt/intel/composer_xe_2015.2.164/bin/compilervars.sh intel64
Except...
mic0$ env |grep LD_LIB
MIC_LD_LIBRARY_PATH=/opt/intel/composer_xe_2015.2.164/compiler/lib/mic:/opt/intel/composer_xe_2015.2.164/mpirt/lib/mic:/opt/intel/mic/coi/device-linux-release/lib:/opt/intel/mic/myo/lib:/opt/intel/composer_xe_2015.2.164/ipp/lib/lib/mic:/opt/intel/mic/coi/device-linux-release/lib:/opt/intel/mic/myo/lib:/opt/intel/composer_xe_2015.2.164/compiler/lib/mic:/opt/intel/composer_xe_2015.2.164/mkl/lib/mic:/opt/intel/composer_xe_2015.2.164/tbb/lib/mic
Huh...it doesn't set LD_LIBRARY_PATH, it sets MIC_LD_LIBRARY_PATH. Odd. But does the code run?
mic0$ ./test.phi
./test.phi: error while loading shared libraries: libiomp5.so: cannot open shared object file: No such file or directory
Nope! Well, I will set the path manually.
mic0$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/intel/composer_xe_2015.2.164/compiler/lib/mic
mic0$ ./test.phi
[snip output, but it runs!]
So I went looking and I don't see anything that sets the LD_LIBRARY_PATH from the Intel tools on the Phi.
What am I missing? What file should I be sourcing for this to work?
Thanks!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As you have built a MIC native application which you copy over to mic, you must do the same with required .so libraries, if you haven't mounted your host compiler/lib/mic directory. If you have full privilege on the mic, you can copy to /usr/lib64/, otherwise you will need to set LD_LIBRARY_PATH. MIC_LD_LIBRARY_PATH applies to offload applications (and only on the host side), but (at least for OpenMP library) would be set for you when you set up the compiler environment.
You take risks when you set unsupported options such as -O4, particularly when specified out of sequence, although that doesn't appear to be central to your question.
If you could focus your interests, you might find a succinct explanation if you would open up your search engine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim Prince wrote:I mentioned that I have already done that via the NFS mount.
if you haven't mounted your host compiler/lib/mic directory.
Tim Prince wrote:I did that too. However, I had to do it manually. The Intel compilervars.sh didn't do that for me which I expected it to.
otherwise you will need to set LD_LIBRARY_PATH.
Tim Prince wrote:Thanks for the info on MIC_LD_LIBRARY_PATH. I was curious how that was used. So why doesn't the the compilervars.sh also set LD_LIBRARY_PATH on the Phi?
MIC_LD_LIBRARY_PATH applies to offload applications (and only on the host side), but (at least for OpenMP library) would be set for you when you set up the compiler environment.
Tim Prince wrote:For this particular application the performance boost is better and the risks are very minimal, so it works. :-)
You take risks when you set unsupported options such as -O4, particularly when specified out of sequence, although that doesn't appear to be central to your question.
Tim Prince wrote:I have opened my search engine, and I can't find anything on the best methods for having LD_LIBRARY_PATH auto-set for me. Everything related to the searches for the missing so file say I need to set LD_LIBRARY_PATH. Duh. I figured that out long before I started searching. Everything related to the LIBRARY_PATH says to run compilervars.sh which clearly doesn't work. I have tried various combinations and I am stuck in trying to figure out the best method for having the LD_LIBRARY_PATH loaded. What I can't figure out is why compilervars.sh doesn't set LD_LIBRARY_PATH on the Phi. I have tried a number of the environment scripts as provided by the Intel tools, and none of them set LD_LIBRARY_PATH on the Phi. They only set MIC_LD_LIBRARY_PATH which doesn't seem to work (which, thanks to your explanation, I understand why it doesn't work now). Sure, I can create my own script in my Intel directory and call it but I find it hard to believe that Intel hasn't already provided a script to solve this exact problem. Also, when creating my own script, I take the risk that I miss or add directories to the LD_LIBRARY_PATH that I shouldn't have. So, what is the correct way to load the LD_LIBRARY_PATH on the Phi? Thanks!
If you could focus your interests, you might find a succinct explanation if you would open up your search engine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If your mount is working and you can see the libraries (e.g. with ls) on the mic side, then making LD_LIBRARY_PATH consistent should work. You might be able to extract a script from compilervars.sh to set LD_LIBRARY_PATH on the mic.
I don't know the pros and cons of why there is no extension of compilervars.sh to extend the setup to mic, other than that the big data centers each want to do their own thing.
In a somewhat analogous situation, there was a script provided with Intel MPI in the past to set ssh permissions but it seemed not to have been maintained for mpss upgrades. Maybe if things ever settle down some of the things can be standardized.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By default, the process that micnativeloadex starts on the coprocessor runs as user micuser - hence the inability to read a file out of your home directory. In general, NFS mounting your home directory is a good thing but in this case it doesn't help you. Using micuser allows the coprocessor to be configured without enabling user login capability.
micnativeloadex does not need to set LD_LIBRARY_PATH on the coprocessor. It finds all the libraries it needs on the host using MIC_LD_LIBRARY_PATH, then copies those libraries and your program up to a tmp directory on the coprocessor - the same directory where it was looking for your input file. It does not count on anything on the coprocessor being located in a particular location.
The Intel compilers are designed to run only on the host, not the coprocessor; consequently the scripts in the composerxe directory are intended to run only on the host. We might be able to provide a script similar to compilervars.sh which could be used if the administrator chooses to NFS mount /opt/intel from the host over to the coprocessor. However, as Tim pointed out, many administrators of larger systems have particular ideas about where they would like things installed - often for very good reasons - so we don't want to get in their way. In those cases, it would be easier for the administrators to write their own scripts.
It would be nice if there was an option on micnativeloadex that allowed you to list your input files and have them copied over the working directory automatically. If you are feeling ambitious, you can find the source code for micnativeloadex in mpss-<version>/src/mpss-coi-<version>.tar.bz and add such an option yourself. Or you can submit a feature request ticket at https://premier.intel.com. The thing with doing the change yourself is that you can have the capability more quickly. The thing with submitting a feature request is that it will take longer but you won't need to worry about rebuilding micnativeloadex each time you upgrade the MPSS.
So, that's the story and I hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Frances Roth (Intel) wrote:I understand that admins might want to install software packages differently, but I am not sure why it matters. My version of compilervars.sh has the $PROD_DIR set in it. I could easily change it to /my/special/location/or/whatever , install the Intel tools there, and it would work. Right? There is a disconnect in my brain between why the location matters and why the compilervars do not set the path on the Phi. So if I am missing something obvious here, please let me know. :-D
...many administrators of larger systems have particular ideas about where they would like things installed - often for very good reasons - so we don't want to get in their way. In those cases, it would be easier for the administrators to write their own scripts.
Frances Roth (Intel) wrote:I think that is the best explanation I have heard for why the compilervars.sh doesn't work on the Phi. However, if I have a OpenMP program that I want to run on the Phi and I can't run it manually because LD_LIBRARY_PATH isn't set and I can't run it through micnativeloadex because it won't read in files from my /home directory...then how am I supposed to run my OpenMP program?? On a semi-related note, my work sponsors us to have access to a digital library. I found a PDF for Colfax's Parallel Programming and Optimization with Intel Xeon Phi Coprocessors. With just a few minutes of skim reading a select few sections I have found answers to several questions that I have or would have solved a lot faster if I had read this book before I high-dived into the Phi. I think this will be my weekend reading and once I work my way through some of the more relevant sections to my code, I will take another stab at it. Maybe it has the answer for how I am supposed to run my OpenMP code on the Phi. :-) Thanks again Tim and Frances!
The Intel compilers are designed to run only on the host, not the coprocessor; consequently the scripts in the composerxe directory are intended to run only on the host.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page