Intel® Software Network

I was looking in my 32-bit installation yesterday, and couldn't find static versions of this library.  Maybe the linker has the same issue.

Patrick,

I see now that in Visual Studio 2008 Microsoft did the same stupid thing. Sigh.

In my opinion, since the OpenMP is also part of the runtime (in the sense that it contains functionality needed at program run-time), it should exhibit the same behavior as the C and C++ runtime libraries with regards to linking. In other words, specifying /MT for a project with no external dependencies should produce a standalone executable.

I understand the motivation behind the change, and I am fully aware of the problem caused by multiple statically linked OpenMP libraries (I faced it myself), but this is one of those cases where I believe the opt-in strategy would be a much better solution. I would leave /MT switch alone and add /Qopenmp-link:dynamic. That way the default for simple projects (single .EXE or .DLL) would be to link statically, and you could always override it for more complex projects.

Guys - Slightly off topic, but related.  The latest linpack (10.1) for windows asks for that same file to run (libiomp5md.dll).  I have been googling in an attempt to locate it so I can run linpack, but to no end.  Where can one obtain libiomp5md.dll?

 

 

You see, that is exactly what I have been expecting to hear. Since /MT no longer means "produce standalone executable" and the setup build process for linpack is most likely automated and doesn't check binary dependencies (which can't be checked without installing on a clean computer and attempting to run the program with human supervision after each build) it failed to include newly required OpenMP DLL.

That mishap is precisely the reason why such behavior changes should be opt-in.

With that said, I am expecting to see more customer reports like this one as people start using 11.0 instead of 10.1 compiler in their projects because the change wasn't properly documented in the compiler Release Notes.

In this case Intel followed suit after Microsoft introduced identical change in their compiler, but in my opinion they didn't have to copy the bad part of Microsoft's decision -- they could have done it smarter.

 

 

I presume you are asking about Windows version?

You could do one of the following depending on how involved you want to become:

1. Submit a problem report on Premier Support (https://premier.intel.com/). If you are not already registered, you can register for free (package ID to report is: w_lpk_p_10.1.0.002)

2. Post the report about missing DLL along with a link to the download page in the Intel Math Kernel Library forum and wait for someone from Intel to read it, address the issue and publish new download.

3. Download and install the trial version of Intel Math Kernel Library which should contain the required DLL.

The option #3 would be the easy way out. Personally I would go for the option #1 because I am pedantic -- if Linpack is a standalone download (and it is) it shouldn't have unresolved dependencies.

If you find my answer helpfull please rate my post. Thank you.

 

Slightly off-topic - but still related to the thread subject - 

I did probably fall into problem related to this 'new' /MT behaviour - first of all - I am NOT using OpenMP (however I'm using parallerisation) - therefore I do not expect that my executable is dependant of any OpenMP library.

What a surprise - when I do start the program - on one of my PC I can see quite annoying message: 

Cannot find import; DLL may be missing, corrupt, or wrong version

File "libguide40.dll", error 998

 

Well - using /MT - I was sure that all the libs are statically linked (I'm wrong - ok) - but why the hell libguide40 is requested by my executable? In your help it is written that it is used only for OpenMP support - there is no information that it is used for paraller option. Or OpenMP library is required also due to other compiler settings / other libraries?

With previous version of Intel Compiler I had no such issues btw.

 

Thanks,

Stan

 

 

Stan,

Auto-parallelization (using -Qparallel) uses OpenMP. Therefore you fell into the trap of a poorly documented breaking change of /MT switch behavior which I described above.

As I said this is Microsoft's screwup to begin with -- they were the first to decouple OpenMP linkage from CRT linkage and in my opinion they did it in a completely wrong way.

I understand the neccessity of the change, but /MT switch always implied standalone executable, and OpenMP itself (however decoupled it may seem because of being in a separate library) is still part of the language, and thus should be treated in the same manner as the language runtime.

What I would really like to know is why OpenMP was put into the separate library to begin with?

Why it wasn't handled in the same manner as the CRT when it comes to multiple inclusions?

If I remember correctly you can safely link several library and object files which are all referencing CRT functions as long as they use the same linkage type (all static or all dynamic). Why OpenMP wasn't made a part of CRT is really beyond me. It would be nice if someone knowledgeable from Intel could answer that.

 

Not so much off topic.  /Qparallel generates OpenMP run-time code automatically, rather than by use of directives.  At link time, /Qparallel and /Qopenmp are equivalent.  With 11.0, both should use libiomp5, and it should be possible to use them together, with OpenMP directives taking precedence.

Currently, I have the 11.0 64-bit linux compiler up, and I notice that combined OpenMP and parallel with -msse3 is compensating for some missed-vectorization cases, including sometimes transform(), and a case where optimization has been reserved for -xsse4.1 since that hardware feature was introduced.  However,  -parallel nearly always loses for the non-vectorizable cases.  When -openmp is removed, -parallel will parallelize most of the OpenMP loops, but not always with the right schedule, and with threading kicking in for cases which are too small to break even.

The point is that the -openmp link option works for the object built with -parallel, as the two are the same at link time.  The writers of the documentation should take your point about including /Qparallel in the remarks which apply to both /Qparallel and /Qopenmp.

 

 

Tim,

Thanks a lot for clarification. It's a pity, there was no remark that QParaller is using OpenMP - and we have to learn that with a pain. Anyway - having an error on one of my PC that libguide40.dll is not working (and having no time to check the reason. This is related probably to older version of the DLL??) - I have really no choice other than link static the lib. 

From all the above messages - in fact - I did not caugh-up the real reason why static link is not a solution (seeing size of my program growing from 2200 up to 2350 - explanation that it's a matter of size does not sound reasonable for me).

But let it leave, still I found this compiler much better than MS one.

 

Stan

 

Stan,

Executable size doesn't have anything to do with this. The problem they are trying to avoid by dynamic linkage of OpenMP library appears if you for example use statically linked OpenMP in several components in your project (say EXE and a DLL) -- then you have multiple initializations of the OpenMP library at startup which may cause all sorts of issues to creep up.

 

I don't think the discussion quite captures all the changes in 11.0, so I'll try to summarize.

In the 11.0 compiler, the libiomp5...  OpenMP runtime libraries have become the default instead of libguide...
The functionality is the same, but the new libraries are also compatible with the Microsoft implementation of OpenMP, (and on Linux, they are compatible with the gcc implementation). Eventually, the libguide versions will be discontinued. There is a switch /Qopenmp-lib: that allows you to choose between the values 'compat' (libiomp5...) and 'legacy' (libguide...) to change the default.

As noted above, the implementation of /Qparallel (auto-parallelization) also makes use of the same OpenMP runtime library. It was an accidental omission (bug) that the 11.0 compiler continued to link libguide... instead of libiomp5... when building with /Qparallel. That's the known issue to which Jennifer was referring, and it will be fixed in an update before too long.

Then, the default linkage for the OpenMP library has changed from static to dynamic, even when /MT is specified. There is a new switch /Qopenmp-link:static that can override this.
This is well covered in the main discussion.

Hi Igor,
I am running into the same Linpack issue - missing libiomp5md.dll. I got the dll; where should i put it? which folder?
Thanks,
Sree

Don't bother; i got it.
Thanks,
Sree

You put it in a folder which is in the PATH or in the same folder with the executable.

I have read this thread, and I am still confused.  I am trying to compile and link statically, using the MKL library for parallel execution.  From the Intel Math Kernel Library for the Windows OS User's Guide, for 32 bit:

Static linking of user’s code myprog.f and parallel Intel MKL supporting cdecl interface:
ifort myprog.f mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib

Similarly for 64 bit:

Static linking of user’s code myprog.f and parallel Intel MKL supporting LP64 interface:
ifort myprog.f mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib

I've included those libraries, and after finding threads here, included the option /Qopenmp-link:static, but my users still get errors about needing libiomp5md.dll.  In the thread above, they talk about libiomp5mt.lib.  Should I be using that one too?  How does that differ from libiomp5md.lib?

The OP talks about the option /MT.  Do I need to include that option?  If so, where do I put it?  The User's Guide just says it's "highly recommended, but doesn't say how to use it.  The release notes don't say either.  Do I just add it as an additional option for linking or compiling (or both)?

Similarly, where should I put the /Qopenmp-link:static option?  Again, none of the documentation says anything.  Right now I have it in the Linker -> Command Line -> Additional Options section, but I'm doing something wrong since I still need the .dll file.


(and why, when I try to paste in this edit window using <ctrl>-v, does it pop up another window that I have to paste my text into (using <ctrl> -v again)?  How is that helpful to anyone??)

Never mind, I didn't realize this was the C++ forum.  I'll start a new thread in the Fortran Forum.

You should do something like
>> ifort myprog.f mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5mt.lib
libiomp5mt.lib is the static lib. libiomp5md.lib is the interface lib for dynamic dll libiomp5md.dll.

About your note on ctrl-v paste, I've reported that as well. I dislike it as well. Also I just heard that using mouse right-click, paste, it works.

Thanks,
Jennifer

Since I've already bumped the thread, I'll ask about this.  I'm compiling a stand alone Fortran command line number crunching code.  We often run two copies simultaneously, in different directories, that are (supposed to be) running completely independently.  Is the "multiple initializations of the OpenMP library" a problem we're going to run into by doing that?


Also, thanks Jennifer, for the libiomp5mt.lib information (and the right-click, paste bit too ;)).  I reported that over in the Fortran forum.

The "multiple initializations" refers to starting up OpenMP more than once in a single process. 
If you are running multiple OpenMP jobs on a single shared memory system, you may see an advantage in specifying each to run on different cache, through use of the AFFINITY and OMP_NUM_THREADS environment variables.

The issue about /Qparallel brings legacy openmp runtime library is fixed in the 1st update. it's posted to the registraction and download center. You can also get it as eval.

Jennifer