OMP abort: Initializing libiomp5md.dll, but found libomp5mt.lib already initialized.

[dashesy]

The application shows the above mentioned message and quickly closes.

I figured out this should be related to some sort of mixed static/dynamic linkage problem.

I am using gcc under MingW to compile all the UMC libraries to create object files, then I create an archive (AR command) to build a library.
I also am linking against FlyCapture SDK which is using static version of OMP (i.e. libiomp5mt.dll), this SDK is thirdparty so I do not have any option. I am sure this SDK is causing the problem since as soon as I remove it the application runs fine.

I would prefer to use the dynamic libraries as much as possible, because of the automatic dispatching advantages while keeping simplicity compared with custom dlls.

Can I use the dynamic IPP libraries (in the stub library folder) to create my object files and then create my archive/lib file, but at the same time link the final application agaisnt the static OMP library (libomp5mt.lib)? I mean, I tried this and it still somehow is linked against the libomp5md.dll

BTW, since I am making the object files (and later my application) without -openmp compiler option, I was thinking that my object files should be linked without OpenMP support, thus will not have problem with 3rd party libraries that do use the OpenMP enabled code.
I mean the 3rd party library uses staticly linked OpenMP libraries and benefits from OpenMP, while the rest of the objects + the final application does not use OpenMP at all, so why I see this error?

[Chao_Y_Intel · Accepted solution]

Hello,

This problem happens because two copies of OpenMP threading libraries are linking into your application. The similar problem can be found in this article:

http://software.intel.com/en-us/articles/opm-abort-initializing-libguide40dll/

The FlyCapture library included the OpenMP library, and your code is linked with IPP dynamic libraries. IPP dynamic libraries are internally threaded with OpenMP, and they will use libiomp5md.dll.

In your application, can you link with static Intel IPP? The static non threaded library does not depends on the OpenMP library. It also automatically help you dispatch your code. (you need to call ippInit() first to initializes the library code for the processor.)

Thanks,

Chao

[dashesy]

IPP dynamic libraries are internally threaded with OpenMP, and they will use libiomp5md.dll.

This was very interesting to know!

In your application, can you link with static Intel IPP? The static non threaded library does not depends on the OpenMP library.

I think I have to use the static libraries, but can you tell me why should it be non threaded? I mean, it seems FlyCapture uses the static threaded OpenMP so why should I use the non-threaded version, is it because perhaps the threaded versions do not have dispatching mechanism or is it something else?
One more question, I am going to use UMC for video coding/decoding/muxing/..., if I use the non-threaded IPP how much performance benefit am I loosing? which IPP libraries are using threading?

I wish the static and dynamic libraries where using two different namespace so they could live together happily!


Thanks

dashesy

[matthieu_darbois]

Hi,

Quote : "I think I have to use the static libraries, but can you tell me why should it be non threaded?"

Since FlyCapture already has libiomp5mt linked in, if you were to link against IPP threaded static libs and libiom5mt.lib that would be once again 2 instances of libiomp for one application which isn't good.

Regards,
Matthieu

[dashesy]

Since FlyCapture already has libiomp5mt linked in, if you were to link against IPP threaded static libs and libiom5mt.lib that would be once again 2 instances of libiomp for one application which isn't good.

Please correct me if I am wrong, there are only two versions of libiomp; namely libiomp5mt and libiomp5md. FlyCapture is linked against libiomp5mt (the static one), so if the IPP threaded static libs are also linked against the static version it should be libiomp5mt again and that would not be 2 different instances. Specially I can make sure that FlyCapture is not doing anything while I am using UMC to code/decode.
I mean, are the threaded static libs linked agaist a different version of libiomp than static libiomp (which is dynamic libiomp5md) because of threading?

Thanks
dashesy

[PaulF_IntelCorp]

Dashesy,

The threaded IPP libraries don't actually contain the OpenMP library. That is, they haven't been linked against either the static or the dynamic version of the library; they have been compiled to reference the OpenMP library, so they include calls to the OpenMP library.

This means that when you link with a threaded variant of the IPP library you must also include the OpenMP library to satisfy those outstanding calls. You can link against either the static or the dynamic version of the OpenMP library, regardless of whether you are using the multi-threaded static IPP library or the multi-threaded dynamic IPP library (the single-threaded static IPP library, by definition,doesn't call the OpenMP library).

In general, the dynamic version of the OpenMP library is the better choice, due to the nature of threading libraries. They need to manage a GLOBAL resource, so two instances of the same library creates a system resource conflict: two OpenMp libraries are trying to manage a single pool of hardware threads. See this article for more about that conflict:

Is there a version of TBB that provides statically linked libraries?

Even though FlyCapture is not being called by you when you use the IPP library, the fact is that the static versionof the OpenMP library that is bound with FlyCapture is still managing threading resources -- and that will conflict with the second instance of OpenMP that you statically bind with your IPP application.

The simplest solution may be to use the single-threaded static IPP library. Only about 15% of the IPP functions are multi-threaded. Check the ThreadedFunctions.txt file to see if the IPP functions you are using are multi-threaded. If none are multi-threade, you're not giving up any performance to use the single-threaded library. If onlyone or two of the functions you are using are multi-threaded you'll have to decide if the performance hit is signficant.

Paul

[matthieu_darbois]

Hi,

You can't only think of libiomp as 2 versions, what's important here is how many libiomp modules are initialized.
I'm thinking, and this is where I might be wrong, that FlyCapture SDK provides you with a stublib and a DLL and therefore, that DLL has been linked with libiomp5mt. That's one isolated instance of libiomp, therefore, you'can't have any other module linked with libiomp (either mt or md). However, if FlyCapture SDK provides a static lib version where you have to specifically link against libiomp in order to get it working, then it might work as you'll end up with only one instance of libiomp for your application.

Regards,
Matthieu

[Chao_Y_Intel]

Quoting matthieu.darbois

I'm thinking, and this is where I might be wrong, that FlyCapture SDK provides you with a stublib and a DLL and therefore, that DLL has been linked with libiomp5mt. That's one isolated instance of libiomp, therefore, you'can't have any other module linked with libiomp (either mt or md). However, if FlyCapture SDK provides a static lib version where you have to specifically link against libiomp in order to get it working, then it might work as you'll end up with only one instance of libiomp for your application.

I agree with Matthieus comment. If FlyCapture is dynamically linking with OpenMP library ( using libiomp5md.dll ). It is fine to link IPP dynamically with OpenMP library. Both FlyCapture and IPP threaded librariescan share one DLL copy of libiomp5md.dll. But if OpenMP library libiomp5mt has been statically linked into FlyCapture's DLLs, it needs to avoid adding any copy of OpenMP library from IPP.

Thanks,
Chao

[dashesy]

Thank you all for very informative posts!

That explains why most of the new releases of develpoment environments (like MATLAB) rely on the dynamic libiomp (shipped with libiomp5md.dll).

Matthieu,

I'm thinking, and this is where I might be wrong, that FlyCapture SDK provides you with a stublib and a DLL and therefore, that DLL has been linked with libiomp5mt. That's one isolated instance of libiomp, therefore, you'can't have any other module linked with libiomp (either mt or md).

You are right, thanks for the infomation.
I asked the developers of FlyCapture SDK to optionally provide a dynamically linked (with libiomp5md.dll) stub lib for developers that need to link against IPP themselves.
I also forwarded them to this thread for more information.
Before then I am going to stick to the single threaded OpenMP.

dashesy