libmmd.dll symbol changes between compiler releases cause trouble

[Mick_Pont]

The compiler run-time math library libmmd.dll can change its contents from release to release of the compiler. Usually that's not a problem, but sometimes symbols can appear or disappear from the library.

At NAG we build libraries with ifort, and redistribute libmmd.dll with our libraries. Our users sometimes complain that they have other copies of libmmd.dll on their systems, which are incompatible with the ones we distribute. This can break their applications which depend on NAG libraries, or break their other applications, depending on how their PATH environment variable is set up. Naturally they then complain to us about it.

I think that the recommended solution is to copy libmmd.dll into the same directory as the executable that needs it. The problem with this is that if you have many applications all depending on the NAG Library, you can end up with many copies of libmmd.dll lying around all over your system. Certainly our users don't like the idea - they would prefer one copy of this library (and other run-time libraries).

I would like to suggest that run-time libraries like libmmd.dll should have version numbers attached, which could be upgraded when the contents become incompatible. I guess that for our purposes we could avoid this problem by renaming the dll to something else, and using an object file editor to hack the internal name of the library to match. I doubt very much though that the Intel compiler team would approve of this idea.

Does anyone know of any other good way around the problem?

Mick Pont
Numerical Algorithms Group, Oxford

[Arjen_Markus]

Just a hunch, but perhaps the library libmmds.lib is the static version og libmmd.dll?
They seem to contain similar symbols.

Regards,

Arjen

[Mick_Pont]

Thanks Arjen - I think you're right about libmmds.lib, but the NAG Library is distributed as a DLL. Even if we could build libmmds.lib into the NAG DLL I'm not sure it would be the right thing to do.

[Arjen_Markus]

An alternative to putting copies next toeach copyt of the NAG library could be to use a similar
scheme as is done for the MSVC runtime libraries: use a manifest file to find the right version.

(Luckily I do not know the details of how you should achieve that - I have been confronted with
problems regardingmanifest files on more than one occasion and although I think we have been
able to solve them each time they arose, it was a nightmare, especially if the client was not
allowed toinstall these DLLsthe recommended way. Just understanding what they are all about
requires either thorough study of the arcane documentation that is scattered over the Internet
or smoking funnycigarettes ... and I do not smoke - sorry, this is frustration seeking a way out)

Regards,

Arjen

[TimP]

The libraries are said to be tested for compatibility in a forward direction. For example, if all .obj files were built with compilers 11.0 through 12.1, the 12.1 .dll should work. It may well work over a wider range, but it may not have been tested.
I suppose it would be difficult to examine the customer's situation during installation and avoid adding an old .dll when a more up to date version is present, or warn about the presence of an older .dll while adding the new one.

[Steven_L_Intel1]

If a symbol disappears from the DLL, I would consider that to be a bug. Can you give an example?