"ImportError: DLL load failed:..." under Windows

[oberbichler]

Hi! The ExternalSolversApplication throws the following error if you use MinGW 7.x and the new libgfortran-4.dll:

ImportError: DLL load failed:...

Installing MinGW 6.x (no need to uninstall the other version) which comes with the old libgfortran-3.dll solves the problem.

[RiccardoRossi]

@roigcarlo can we package the libgfortran in the windows package?

[roigcarlo]

Should be already there... Which application were you importing when this happened?

El sáb., 2 dic. 2017 10:45, Riccardo Rossi notifications@github.com escribió:

@roigcarlo https://github.com/roigcarlo can we package the libgfortran in the windows package?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/1114#issuecomment-348680888, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2Jr2SucVqA04Zv75_V11ACguPxLnRfks5s8RxNgaJpZM4QyYyx .

[oberbichler]

It happens while importing the ExternalSolversApplication after following the Windows-Build guide from the wiki. I added the version number to the wiki but I think the article needs some additional rework.

[roigcarlo]

But this is for the release?

El sáb., 2 dic. 2017 11:08, thomas notifications@github.com escribió:

It happens while importing the ExternalSolversApplication after following the Windows-Build guide from the wiki. I added the version number to the wiki but I think the article needs some additional rework.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/1114#issuecomment-348681965, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2JrzWIORYXzwNUifDxxrQSWfionenmks5s8SGVgaJpZM4QyYyx .

[roigcarlo]

Ok, there was something odd with the wiki and it was "hard to read". I restored the style. Anyway, it explicitly says that you need to copy that DLL:

I will try to make cmake copy them automatically, but then we have to add some -DMINGW_PATH.

[oberbichler]

It says that you should copy all dll's from the MinGW folder. With the default settings MinGW installs version 7.2 which contains libgfortran-4.dll. Kratos needs libgfortran-3.dll -> Exception when importing ExternalSolversApplication

The important information is to select version 6.4 during the installation of MinGW

[roigcarlo]

That's odd. Is this for the 64 version? Actually this should be the other way arround. In any case you should always select the last version from mingw, if we have to change something is the libblas and liblapack. The link in the wiki is for an older version since they tend to have separate update cycles. I'll take a look at home.

[philbucher]

this might be interesting for @KlausBSautter

[oberbichler]

Yes. It is for x64. Probably libblas and liblapack are compiled with libgfortran-3.dll but this is just a guess. Everything works fine after selecting the correct version. I opened this issue for people with the same problem.

Btw: Yesterday I added wrappers for a header-only solver and Pardiso to Kratos. The header-only solver could avoid the MinGW dependencies. It seems that also the performance is equal/better as SuperLU under Windows but I have to check that again.

[roigcarlo]

@oberbichler I've just check the libbas and lapack lib dependencies for win in their latest version and they still have not updated to libgfortran-4 ( and from what I've been told they have no plans to do so), so I'll change the wiki with your solution (going back to 6.X).

@RiccardoRossi we will probably have to start to consider devoting some time to compile our own libblas/liblapack to keep up with the release cycle of MinGW so this problems can be avoided.

[oberbichler]

In the branch feature-eigen_solvers I have integrated the SparseLU solver from the Eigen library. It comes with an own blas/lapack implementation which seems to be very fast. It is header-only so it works without the precompiled libs and also without MinGW.

Just add the following definitions to the configure.bat:

-DEIGEN_SOLVERS_APPLICATION=ON ^
-DEIGEN_ROOT="<path to eigen>" ^

It optionally also integrates some Pardiso solvers if you run the configure script from Intel MKL before CMake. Then you would need the MKL dlls. When you don't have MKL you just don't have these solvers available.

[roigcarlo]

@oberbichler That would solve the issue with blas. In fact, if you have them, you can use MKL libs as as BLAS/LAPACK implementation, we usually do that in clusters.

The reason that we don't explicitly state this in the wiki is MKL licencing issues. Eigen internal BLAS/LAPACK is (as far as I know) very efficient for 1 single core, but not for multicore, which I suppose is why you have included the PARDISO solvers, which require the MKL DLL's. Sadly we cannot even redistribute the "community version" of MKL as its licence does not allow it, and we have not purchased the full version, which do allows it.

[oberbichler]

That's why I made the MKL integration completely optional (no MKL stuff inside Kratos).

You are right! Eigen BLAS/LAPACK is single core. But in my examples it is much faster than SuperLU. Maybe the performance depends on the problem type or maybe this is a Windows-thing. Anyway: Eigen don't need any precompiled libraries. If the speed is at least comparable with SuperLU it might be a good alternative.

The idea of this application is, that we want to try out some algorithms for eigenvalue-computation that are based on the eigen library. Everything works without MKL. But if the user has MKL he can easily activate it.

[armingeiser]

@roigcarlo Do I understand this right, that everyone is allowed to download MKL on its own and use it, but the redistribution of the dlls/libs is not allowed. So for developers under Windows, using MKL would be kind of a similar effort as currently with MinGW, but with the downside, that the release version of Kratos shipped with GiD would not contain the necessary libs?

Do you happen to know if companies are allowed to download MKL?

[roigcarlo]

Yes, basically this is the situation, just a small clarification:

• MKL redistribution is not explicitly prohibited, but last time we check it had conflicts with BSD. I will recheck that since while writting this I saw they have updated the licence to ISSL. @KratosMultiphysics/technical-committee can you take a look at Intel ISSL?
• If you want to use MKL instead of MinGW you also have to select them as the implementatio for BLAS and LAPACK, which can be done as we usually do it in clusters, but I've never tried on win.

And yes, everyone can download MKL, being a company is not a problem.

[RiccardoRossi]

Hello, to give my 2cents: i am also not sure that Eigen can be distributed together with Kratos. To me it is NOT clear if the MTL license allows this, so i think it is good to have it as an application rather then integrated in the core.

[oberbichler]

@roigcarlo BLAS/LAPACK linking should be done automatically by Eigen. Works fine under Windows. Still some problems under Linux...

@RiccardoRossi total agree with the application approach. Is Eigen MPL2?

[armingeiser]

@RiccardoRossi from "https://www.mozilla.org/en-US/MPL/2.0/FAQ/"

"Q13: May I combine MPL-licensed code and BSD-licensed code in the same executable program? What about Apache?

Yes to both. Mozilla currently does this with BSD-licensed code. For example, libvpx, which is used in Firefox to decode WebM video, is under a BSD license."

As far as I understand, this should be possible

[RiccardoRossi]

can u pose the question on the eigen blog? if they say yes than to me it would be ok

[armingeiser]

@oberbichler eigen is MPL2 from version 3.1.1