Hmmm... Thanks, Jeremiah, for the suggestion.
File win_compat.h is in directory opal/win32 , a directory which by its name is supposedly concerned only with producing a 32-bit target, and so, because we are doing a build for a 64-bit target, it seems make should not be having anything to do with files in that directory. What seems a more likely approach is to consider what happens in asm.c , which appears to be where make has problems. I gather that either some command is executed to create asm.lo earlier in the make processing (although make output does not show any earlier command to do that) or else, which seems more likely, gcc (in command " CC asm.lo " ) knows how to interpret the file name asm.lo so as to look at asm.c for build purposes. So what does asm.c do??? After a bunch of initial #include statements in asm.c there is next the statement #if OPAL_ASSEMBLY_ARCH == OMPI_SPARC But note that directory opal/asm/base has a bunch of files whose names suggest that SPARC is an alternative architecture to AMD64 . So it seems the preprocessor #if condition should evaluate to false. The other end of this #if statement is #endif /* OPAL_ASSEMBLY_ARCH == OMPI_SPARC32 */ at the very end of the file. So it seems the result is that there is no code in asm.c to compile (or assemble); the resulting preprocessed file consists only of included headers. So I'm thinking that the thing to do is to gut asm.c and replace it with a dummy routine so that at least an object file will be produced so that make will not get confused for lack of an object file. But this assumes that asm.c is not supposed to produce any entry points or other loader variables to link to other modules in Open MPI. That is a big question. One possibility is to find some equivalent 32-bit file alternative to the supposed 64-bit asm.c and to try to manually re-interpret and modify that code so as to become an equivalent 64-bit code. So maybe I should do a 32-bit build and somehow adjust the relevant Makefileso that a file of 32-bit preprocessed C or assembly code is produced from asm.c But I suppose this would require knowing what the command "CC asm.lo" is actually supposed to do even in the 32-bit case. I am wondering whether such a 32-bit "build" for preprocessed output from asm.c can be done as a quick, stand-alone run without having to rerun configure and make for context. --- Note also the OMPI_SPARC32 in the comment for #endif . That suggests the author may have been vacillating as to whether SPARC is a 32-bit architecture. There is likely lots of guessing in this approach; so unless someone can suggest a more direct and definitive solution to resolve this issue fairly soon, I think I may take a little vacation and perhaps come back to this question later. Richard Haney On Tue, Aug 20, 2013 at 7:41 PM, Jeremiah Willcock <jewil...@crest.iu.edu>wrote: > The file win_compat.h seems to be very strange (many #defines of function > names, #defines of type names rather than typedefs, etc.). It might make > sense to avoid including it entirely for MinGW (it is included from > opal/include/opal_config_**bottom.h), or edit it to be correct for 64-bit > systems. You might want to try commenting out the entire body of > win_compat.h and re-enabling only those parts that are truly necessary (and > don't have MinGW headers that should be used instead, such as for ssize_t). > > -- Jeremiah Willcock > >
