Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

Old dll in SYSWOW64

Matthias_Schumacher
288 Views

My 32Bit-Fortran program breaks due to an unsolved symbol in libmmd.dll.

The entry point pow2o3f seems to be quite new in this dll.

So I updated the redistributable libraries with the msi-package, but the file in SYSWOW64 remains the old one.

Obvoiusly the OS looks first in this directory to find the dll, then the program fails.

When I rename this dll in SYSWOW64 to something temp., it works.

Should I freshen up SYSWOW64 by myself or what to do?

Kind regards

  Matthias

 

0 Kudos
1 Solution
Steve_Lionel
Black Belt Retired Employee
288 Views

That DLL should never have been placed in SYSWOW64 - Intel installers don't do that. Remove it from there. I have seen third-party installers copy language runtime DLLs to the Windows System folder because they don't want to add to PATH or use side-by-side installs.

View solution in original post

8 Replies
Steve_Lionel
Black Belt Retired Employee
289 Views

That DLL should never have been placed in SYSWOW64 - Intel installers don't do that. Remove it from there. I have seen third-party installers copy language runtime DLLs to the Windows System folder because they don't want to add to PATH or use side-by-side installs.

View solution in original post

Matthias_Schumacher
288 Views

Hello Steve,

 

thanks for yur valuable reply.

I meantime I found out, that deleteing or renaming the dll is not enough, because some of our third party software recreates the missing dll from the installation package.

Is it possible to create an application config in an easy manner to ensure that DLLs with a minimum version are used?

It seems to me, that this for a .NET-application, but not for a console aqpplication, as mine it is.

 

Kind regards

  Matthias

Steve_Lionel
Black Belt Retired Employee
288 Views

It's possible, sure. This is what Microsoft's side-by-side installs with application manifest does for you. Microsoft uses this itself for MSVC DLLs and has for many years.

A long time ago, the Intel libraries team looked into this and was discouraged from doing so by Microsoft, saying something better was coming along. It never did. I repeatedly asked the libraries folk to revisit this, but was unsuccessful.

I'm unsure if you can set things up yourself to use SxS for the Intel DLLs, as I think those DLLs themselves need to be built with the proper manifests. I may be wrong about this, so it's something to investigate. But even if you could, you'd have to "install" those DLLs yourself which isn't really any better.

Please complain to the third-party tool developers - what they are doing is blatantly wrong and will break applications for their customers. Rather than blindly copying other vendors' DLLs into the Windows system areas, they should use the appropriate redistributables installers. Intel provides one for its DLLs that can be integrated into product installs.

Unfortunately, the Windows System folder is searched before PATH. I looked for various ways around this but didn't find any, other than copying the correct DLL into the same folder as your EXE, which is almost as awful a solution.

jimdempseyatthecove
Black Belt
288 Views

>>libmmd.dll ...  because some of our third party software recreates the missing dll

Does that version of libmmd.dll exist elsewhere on the system?
If so, can you rename that (or move it to a safe place).

Does the application that re-installed libmmd.dll run without the renamed/moved libmmd.dll?
IOW, does it re-create the old version of libmmd.dll from an archive? Or complain about missing .dll and quits. Or behaves badly using the new .dll?

The .NET application may include a "download missing .DLL" feature. If so, and it downloads and installs libmmd.dll from somewhere try deleting the SYSWOW version, and add to PATH your preferred version's folder and see what happens. (Note, the ...\IntelSWTools\... should already be there).

Jim Dempsey

Matthias_Schumacher
288 Views

So the easy way is to use static linking?

Steve_Lionel
Black Belt Retired Employee
288 Views

Static linking would certainly be a way around this, though I hate to recommend it in general.

Matthias_Schumacher
288 Views

@Jim: I renamed it, but it came again...

jimdempseyatthecove
Black Belt
288 Views

Have you determined where it is coming from?

       C:\>DIR \libmmd.dll /s /b

That will find it (and all libmmd.dll's) that are in plain view (even in hidden folders). Also the CMD window version is much faster than Windows Explorer (which won't search hidden folders below the start point)..

If that fails to identify the file, then the dll is likely in a compressed archive (Windows Explorer may find that as it searches archives too).

If you are unable to locate the source, then try to identify which application performs the copy. Once identified, you can write a shortcut .bat file that launches this application, and then on application close, delete the syswow version of the dll.

Jim Dempsey

Reply