Deployment of an Application

[acar]

A question on application deployment. I have successfully installed on my W7 and Vista machines but not on an XP machine where libiomp5md.dll was missing. I have found the relevant msi redistribution files from the Intel website but have a couple of questions:

1) if this is the only dll that is missing then do I really need to get my users to over-write any existing dlls with ones that are not needed for my application - is there a way of telling what dlls my application needs and then distributing and presumably registering them seperately?

2) I've found threads discussing te possibility of using static libraries rather than dlls. This would clearly solve this problem but are there any repercussions?

Thanks in advance for your help. ACAR

[TimP]

1) dumpbin /dependents is among the tools to show which dlls your exe requires. No need to install any dlls which aren't needed. dlls in use whcih are supplied by Microsoft are expected not to run into versioning problems.
2) ifort does default to static link for a majority of its libraries, libiomp5 being an exception. As a result, the exe is fairly large even for a small application. The OpenMP library defaults to dynamic link on the theory that this is less liable to mistakes such as linking bits of various OpenMP libraries at various stages of a build.

[Steven_L_Intel1]

You can use Dependency Walker to see which DLLs your application needs. You can place Intel DLLs in the same folder as your EXE if you don't want to get involved with installing them. Note that your aspplication may be dependent on Microsoft Visual C++ DLLs as well, and for those you must use Microsoft's installer.

You can use static libraries, sure. The OpenMP library (libiomp5) is linked dynamically by default but you can specify a static link using /Qopenmp-link:static This is not recommended if you're also linking to other DLLs that use OpenMP.

See also this article on deployment.

[acar]

Could I ask what is the best approach for redistribution. It seems to me, in the absence of any information about the target system, that the safest bet is to redistribute the Intel and MS redsitributables and get my installer to install them on the target system. But doing this may alter the target systems behaviour which might quite rightly upset a potential customer. Alternatively I could put all the dlls in the application directory on the target machine without registering them on the target system but by location my application will find and use them as required? I have used dependency walker as suggested and it is flagging a warning on the ieframe.dll : unresolved import due to missing export function (whatever that might mean). Is it just me or is it that this process is unecessarily amiguous and overly complicated?

[TimP]

Aside from taking disk space, the redistributable libraries don't appear on a standard PATH. Unless you add them to general Windows search paths, they won't alter behavior of the system.
ieframe.dll is a Microsoft library; as far as I know, it's not connected with ifort libraries or redistributables.
I won't disagree if you consider Windows ambiguous and complicated.

[IanH]

Quoting TimP (Intel)

Aside from taking disk space, the redistributable libraries don't appear on a standard PATH. Unless you add them to general Windows search paths, they won't alter behavior of the system.

I'm pretty sure that if you deploy the redistributables via the intel supplied merge module or msi (talking redistributables only here) then you'll find the system path gets updated to include them or the Intel provided msm/msi wouldn't be much chop. (I think I've whinged previously about the length of the addition to the path due to the Intel DLL's going in multiple directories under an otherwise common parent directory).

The way I do it is to dynamically link and just have the VS and Intel redistributable merge modules as part of the app's install (which are just VS 2005 deployment projects). Simple, relatively robust. Downsides:

• msi file is a bit bigger.
• On one occasion the installation for another Intel Fortran based app saw fit to put the intel fortran dll's in system32, which caused versioning issues due to their copy of the runtime being older than the one I needed (to those reading - if your install does this then please fix it - actually, in the case of the app that caused me trouble don't stop there - there's plenty of other things that you need to fix too!).
• If you need to run fortran code (or even just load fortran based DLL's) during the install then that specific code needs to either be statically linked or you need to be very careful about sequencing and whether changes to the path made by the installation process are visible to your program (installations run under system not user accounts, etc)

If you don't deploy the VC redistributables with your app then don't complain when MS push out a patch that causes the version on your development machine to get out of sync with your customers.