11.0.061 OpenMP issue -- libiomp5md.dll required to run apps compiled with /MT

11.0.061 OpenMP issue -- libiomp5md.dll required to run apps compiled with /MT

Igor Levicki's picture

As the title says, libiomp5md.dll seems to be required to run applications compiled with /MT switch which I believe to be an error. If Iselect static linking I mean it!

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
27 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - Igor Levicki

As the title says, libiomp5md.dll seems to be required to run applications compiled with /MT switch which I believe to be an error. If Iselect static linking I mean it!

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.

Igor Levicki's picture

Nope, the file (libiomp5mt.lib)is there, your install is either corrupted or you looked in the wrong folder --folder hierarchy has changed with 11.0.

There is a workaround with specifying/nodefaultlib:libiomp5md.lib, and addinglibiomp5mt.lib to the dependency listfor each OpenMP project, architecture,and configuration but that is ugly, tedious and error-prone so I am not going toaccept that.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

The 11.0 Windows compilers (both C++ and Fortran) have decoupled /MT from having any effect on which OpenMP runtime (static or dynamic) gets linked. In fact, all of /MT[d], /MD[d], and /ML[d] (latter VS2003 only) now only effect which MS C runtime is linked.
We made this change because we want dynamic to be the default when linking the OpenMP RTL. The use of static OpenMP libraries is not recommended, because they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results. It can also cause Thread Checker false positives and other problems with the Intel Threading tools.

If you want to link against the static OpenMP RTL, you must add /Qopenmp-link:static, which is a new switch for 11.0. So to produce a purely static executable, compile/link with /MT /Qopenmp-link:static

Patrick Kennedy
Intel Compiler Lab

Igor Levicki's picture

Quoting - pbkenned

The 11.0 Windows compilers (both C++ and Fortran) have decoupled /MT from having any effect on which OpenMP runtime (static or dynamic) gets linked. In fact, all of /MT[d], /MD[d], and /ML[d] (latter VS2003 only) now only effect which MS C runtime is linked.
We made this change because we want dynamic to be the default when linking the OpenMP RTL. The use of static OpenMP libraries is not recommended, because they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results. It can also cause Thread Checker false positives and other problems with the Intel Threading tools.
If you want to link against the static OpenMP RTL, you must add /Qopenmp-link:static, which is a new switch for 11.0. So to produce a purely static executable, compile/link with /MT /Qopenmp-link:static

Patrick Kennedy
Intel Compiler Lab

Patrick,

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

In my opinion, since theOpenMP 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 librarieswith regardsto linking. In other words, specifying /MT for a project with no external dependencies should produce a standalone executable.

I understandthemotivation 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 whereI believe the opt-in strategywould be a muchbetter solution. Iwould leave /MTswitch 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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

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?

Igor Levicki's picture

Quoting - darksky

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Igor - I got the jist of your opinion although I am no programmer :) I'm still wondering what I need to do on my end to run Linpack. Is it as simple as downloading the aforementioned dll and if so, where can I obtain it? I have followed many different google links, but haven't located it anywhere.

Thank you in advance.

Quoting - Igor Levicki

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.

Igor Levicki's picture

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
Stan's picture

Quoting - pbkenned

The 11.0 Windows compilers (both C++ and Fortran) have decoupled /MT from having any effect on which OpenMP runtime (static or dynamic) gets linked. In fact, all of /MT[d], /MD[d], and /ML[d] (latter VS2003 only) now only effect which MS C runtime is linked.
We made this change because we want dynamic to be the default when linking the OpenMP RTL. The use of static OpenMP libraries is not recommended, because they might cause multiple libraries to be linked in an application. The condition is not supported and could lead to unpredictable results. It can also cause Thread Checker false positives and other problems with the Intel Threading tools.
If you want to link against the static OpenMP RTL, you must add /Qopenmp-link:static, which is a new switch for 11.0. So to produce a purely static executable, compile/link with /MT /Qopenmp-link:static

Patrick Kennedy
Intel Compiler Lab

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

cGPSmapper
Igor Levicki's picture

Quoting - kozickigd.onet.pl

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

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.

Jennifer J. (Intel)'s picture

The /Qparallel issue is known, and is being fixed. When the fix is availabe, I'll let everyone know.
Thanks,
Jennifer

Just FYI. I have one customer who reported an OpenMPproblem against libomp5md.dll in 11.0.061. And 11.0.066 has the fix. Probably you want to try 11.0.066 and see if the problem reported in this thread has been fixed.
Feilong

Stan's picture

Quoting - tim18

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

cGPSmapper
Igor Levicki's picture

Quoting - Stan

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
Martyn Corden (Intel)'s picture

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 thegcc 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:staticthat can override this.
This is well covered in the main discussion.

Sreelekshmy Syamalakumari (Intel)'s picture

Quoting - Igor Levicki

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.

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

Sreelekshmy Syamalakumari (Intel)'s picture

Quoting - Sreelekshmy Syamalakumari (Intel)

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

Igor Levicki's picture

Quoting - Sreelekshmy Syamalakumari (Intel)

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.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

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 users 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 users 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 -v, does it pop up another window that I have to paste my text into (using -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.

Jennifer J. (Intel)'s picture

Quoting - blischke
ifort myprog.f mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib

In the thread above, they talk about libiomp5mt.lib. Should I be using that one too? How does that differ from libiomp5md.lib?

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

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

Quoting - Igor Levicki

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.

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.

Jennifer J. (Intel)'s picture

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

I agree with Igor: /MT should be as absolute as ever, creating clean .exe files without external runtime-dll needs.

Login to leave a comment.