On Mon, Nov 3, 2008 at 3:04 PM, Jeff Squyres wrote: > On Nov 3, 2008, at 2:53 PM, Gustavo Seabra wrote: > >> Finally, I was *almost* able to compile OpenMPI in Cygwin using the >> following configure command: >> >> ./configure --prefix=/home/seabra/local/openmpi-1.3b1 \ >> --with-mpi-param_check=always --with-threads=posix \ >> --enable-mpi-threads --disable-io-romio \ >> --enable-mca-no-build=memory_mallopt,maffinity,paffinity \ >> --enable-contrib-no-build=vt \ >> FC=g95 'FFLAGS=-O0 -fno-second-underscore' CXX=g++ > > For your fortran issue, the Fortran 90 interface needs the Fortran 77 > interface. So you need to supply an F77 as well (the output from configure > should indicate that the F90 interface was disabled because the F77 > interface was disabled).
Is that what you mean (see below)? I thought the g95 compiler could deal with F77 as well as F95... If so, could I just pass F77='g95'? (From the configure output) *** Fortran 90/95 compiler checking whether we are using the GNU Fortran compiler... yes checking whether g95 accepts -g... yes checking if Fortran compiler works... yes checking whether g77 and g95 compilers are compatible... no configure: WARNING: *** Fortran 77 and Fortran 90 compilers are not link compatible configure: WARNING: *** Disabling MPI Fortran 90/95 bindings checking for extra arguments to build a shard library... none needed checking to see if F90 compiler likes the C++ exception flags... skipped (no F90 bindings) > >> I then had a very weird error during compilation of >> ompi/tools/ompi_info/params.cc. (See below). >> >> The lines causing the compilation errors are: >> >> vector.tcc:307: const size_type __len = __old_size + >> std::max(__old_size, __n); >> vector.tcc:384: const size_type __len = __old_size + >> std::max(__old_size, __n); >> stl_bvector.h:522: const size_type __len = size() + std::max(size(), >> __n); >> stl_bvector.h:823: const size_type __len = size() + std::max(size(), >> __n); >> >> (Notice that those are from the standard gcc libraries.) >> >> After googling it for a while, I could find that this error is caused >> because, at come point, the source code being compiled redefined the >> "max" function with a macro, g++ cannot recognize the "std::max" that >> happens in those lines and only "sees" a (...), thus printing that >> cryptic complaint. >> >> I looked in some places in the OpenMPI code, but I couldn't find >> "max" being redefined anywhere, but I may be looking in the wrong >> places. Anyways, the only way of found of compiling OpenMPI was a very >> ugly hack: I have to go into those files and remove the "std::" before >> the "max". With that, it all compiled cleanly. > > I'm not sure I follow -- I don't see anywhere in OMPI where we use std::max. > What areas did you find that you needed to change? These files are part of the standard C++ headers. In my case, they sit in: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits In principle, the problems that comes from those files would mean that the OpenMPI source has some macro redefining max, but that's what I could not find :-( >> I did try running the tests in the 'tests' directory (with 'make >> check'), and I didn't get any alarming message, except that in some >> cases (class, threads, peruse) it printed "All 0 tests passed". I got >> and "All (n) tests passed" (n>0) for asm and datatype. >> >> Can anybody comment on the meaning of those test results? Should I be >> alarmed with the "All 0 tests passed" messages? > > No. We don't really maintain the "make check" stuff too well. Oh well... What do you use for testing the implementation? Thanks a lot! Gustavo.