Solving OpenMPI Problems on Windows

[FunkyDwarf]

Hey gang,

I'm trying to get started with OpenMPI on my windows machine (crazy/stupid I know, one day I will man up and dual boot linux) but I'm running into a few problems.

I can get mpiexec to work fine to run jobs, i.e. examples that come with various installs, but mpicc doesn't seem to want to work.

Specifically, it doesn't seem to find basic libraries used by mpi.h. I get errors like:

fatal error c1083: Cannot open include file: 'stdio.h' no such file or directory.

I have MingW installed for gcc/g++ and they work fine. My environment variable paths are as follows:

C:\OpenMPI\bin;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin;C:\MinGW\bin;

The only reason Visual studio is there is for cl.exe which is apparently needed by MPI. The IDE path is there for some .dll.

Am I doing something stupid (apart from using windows to code on) or missing something obvious?

Thanks!

EDIT:
I tried including
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include
to the path as well and now it can't find stddef.h even though it resides in this folder as well :\

 

[chiro]

Hey FunkyDwarf.

I have a few suggestions.

The first relates to the order of included directories in Visual C++ IDE. Sometimes if they are in the wrong order, weird errors happen and it's mainly got to do with when you have different include file specifications.

The second relates to the nature of the actual include directories themselves. If they are like say http://blogs.msdn.com/b/vsproject/archive/2009/07/07/vc-directories.aspx (scroll down to include screen shot), then you will have more directories to include than the one you mentioned above.

The other thing relates to versions of include files and what comes with each compiler (in this case the VC++ one as part of of the Visual Studio Suite). In this case, wrong versions will tend to create lots of errors.

 

[FunkyDwarf]

Hi chrio,

Thanks for the reply. Just to qualify your statement, do you mean the order of Visual C++ stuff in that program, or in the path I listed?

I'm not actually using VC, I only installed it for the cl.exe file. I'm trying to run everything from command line and I use a different IDE for the programming itself.

I tried seeing if there is a way to do all of this without VC but I'm yet to find one, is it possible?

 

[chiro]

Hi chrio,

Thanks for the reply. Just to qualify your statement, do you mean the order of Visual C++ stuff in that program, or in the path I listed?

I'm not actually using VC, I only installed it for the cl.exe file. I'm trying to run everything from command line and I use a different IDE for the programming itself.

I tried seeing if there is a way to do all of this without VC but I'm yet to find one, is it possible?

One thing that you can do is to use a program that converts the argument list given to cl.exe to an argument list used for say the GNU C (or C++ depending the code) compiler and then simply call the other compiler to compile the code.

If for some reason though the DLL uses some kind of specialized Microsoft functionality (like a .NET, COM, MFC, whatever type structure/interface) then you will need to use the Microsoft Compiler.

For the path information, if you are passing path information to cl.exe then yes it is this order that I'm referring to and the order is important especially if you are using different code-repositories with different versions, or different meanings. For example, if you've ever done windows programming, you may have realized that when you include "windows.h", you are including a plethora of definitions of all kinds and including stuff at the wrong time will give you a tonne of compiler errors associated with redefinitions and other messages that fill the error window in a few seconds (or less).

So if you give a path, pass this to cl.exe in the right order and make sure that the list is also complete.

The other thing is stddef.h is actually synonymous with an application header and not necessarily a standard library or SDK header (it may be, but I do know that certain IDE's set this up to put all the standard application definitions in one place), so you should also make sure if you have special SDK include files, that this directory is referenced before every other include directory.