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
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
asm.c But I suppose this would require knowing what the command "CC
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
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
On Tue, Aug 20, 2013 at 7:41 PM, Jeremiah Willcock <jewillco_at_[hidden]>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