This is my fourth attempt to get past the robot censor. Not even text format passed. If this message passes the censor, it is likely because attachments are considered part of the "body" of the message, which the censor seems to object to due to size. I am deleting the attachments.
Re-sending: On Tue, Aug 20, 2013 at 12:16 PM, Richard Haney <rfha...@gmail.com> wrote: > Thanks Jeremiah, > > Your comments were most helpful. > > I did find where configure sets > > ompi_cv_asm_arch="IA32" > > and subsequently prints out [sic] > > checking for asssembly architecture... IA32 > > I tried changing the 'ompi_cv_asm_arch="IA32" ' to > > ompi_cv_asm_arch="AMD64" > > which was an alternative not chosen in the original configure because my > long has size 4 -- a very puzzling excuse for not using "AMD64". > > A more complete message from me "awaits moderator approval". > > It is a puzzle to me why the OpenMPI issue-reporting info asks for lots > and lots of info, including several compressed files of rather large files > and yet the listserv seems to have rather stringent size limits on the body > of messages. > > It seems as if the original designers and developers and maintainers had > grand, ambitious ideas for OpenMPI but that now the maintainers have > considerably deflated ambitions and hopes for OpenMPI. > > I am new to OpenMPI and I am only trying to build and install it because > an opt++2.4 numerical optimization package I want to install says it has > facilities to use any installed MPI. > > But I am having sooooooo much trouble with trying to build the package > -- specifically trying to get past the make of asm.c in > /openmpi-1.6.5/opal/asm -- that I'm wondering if it is worthwhile. > > Richard Haney > > > On Mon, Aug 19, 2013 at 8:04 AM, Jeremiah Willcock <jewil...@osl.iu.edu>wrote: > > >> ... >> > > >> Are you sure that the code is building with the right assembly file? >> AMD64.asm looks to be using pushq, which is the right form to use for >> 64-bit code. I suspect that this is a configure issue (detecting your >> architecture as IA-32 and not x86-64), not a problem in the assembly files >> themselves. >> >>
