[OMPI users] Problems installing in Cygwin
Hi All, I am trying to install OpenMPI in Cygwin. from a cygwin bash shell, I configured OpenMPI with the command below: $ echo $MPI_HOME /home/seabra/local/openmpi-1.2.7 $ ./configure --prefix=$MPI_HOME \ --with-mpi-param_check=always \ --with-threads=posix \ --enable-mpi-threads \ --disable-io-romio \ FC="g95" FFLAGS="-O0 -fno-second-underscore" \ CXX="g++" The configuration *seems* to be OK (it finishes with: "configure: exit 0"). However, when I try to install it, the installation finishes with the error below. I wonder if anyone here could help me figure out what is going wrong. Thanks a lot! Gustavo. == $ make clean [...] $ make install [...] Making install in mca/timer/windows make[2]: Entering directory `/home/seabra/local/openmpi-1.2.7/opal/mca/timer/windows' depbase=`echo timer_windows_component.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT timer_windows_component.lo -MD -MP -MF $depbase.Tpo -c -o timer_windows_component.lo timer_windows_component.c &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT timer_windows_component.lo -MD -MP -MF .deps/timer_windows_component.Tpo -c timer_windows_component.c -DDLL_EXPORT -DPIC -o .libs/timer_windows_component.o timer_windows_component.c:22:60: opal/mca/timer/windows/timer_windows_component.h: No such file or directory timer_windows_component.c:25: error: parse error before "opal_timer_windows_freq" timer_windows_component.c:25: warning: data definition has no type or storage class timer_windows_component.c:26: error: parse error before "opal_timer_windows_start" timer_windows_component.c:26: warning: data definition has no type or storage class timer_windows_component.c: In function `opal_timer_windows_open': timer_windows_component.c:60: error: `LARGE_INTEGER' undeclared (first use in this function) timer_windows_component.c:60: error: (Each undeclared identifier is reported only once timer_windows_component.c:60: error: for each function it appears in.) timer_windows_component.c:60: error: parse error before "now" timer_windows_component.c:62: error: `now' undeclared (first use in this function) make[2]: *** [timer_windows_component.lo] Error 1 make[2]: Leaving directory `/home/seabra/local/openmpi-1.2.7/opal/mca/timer/windows' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/seabra/local/openmpi-1.2.7/opal' make: *** [install-recursive] Error 1
[OMPI users] Fwd: Problems installing in Cygwin
Hi All, (Sorry if you already got this message befor, but since I didn't get any answer, I'm assuming it didn't get through to the list.) I am trying to install OpenMPI in Cygwin. from a cygwin bash shell, I configured OpenMPI with the command below: $ echo $MPI_HOME /home/seabra/local/openmpi-1.2.7 $ ./configure --prefix=$MPI_HOME \ --with-mpi-param_check=always \ --with-threads=posix \ --enable-mpi-threads \ --disable-io-romio \ FC="g95" FFLAGS="-O0 -fno-second-underscore" \ CXX="g++" The configuration *seems* to be OK (it finishes with: "configure: exit 0"). However, when I try to install it, the installation finishes with the error below. I wonder if anyone here could help me figure out what is going wrong. Thanks a lot! Gustavo. == $ make clean [...] $ make install [...] Making install in mca/timer/windows make[2]: Entering directory `/home/seabra/local/openmpi-1.2.7/opal/mca/timer/windows' depbase=`echo timer_windows_component.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT timer_windows_component.lo -MD -MP -MF $depbase.Tpo -c -o timer_windows_component.lo timer_windows_component.c &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT timer_windows_component.lo -MD -MP -MF .deps/timer_windows_component.Tpo -c timer_windows_component.c -DDLL_EXPORT -DPIC -o .libs/timer_windows_component.o timer_windows_component.c:22:60: opal/mca/timer/windows/timer_windows_component.h: No such file or directory timer_windows_component.c:25: error: parse error before "opal_timer_windows_freq" timer_windows_component.c:25: warning: data definition has no type or storage class timer_windows_component.c:26: error: parse error before "opal_timer_windows_start" timer_windows_component.c:26: warning: data definition has no type or storage class timer_windows_component.c: In function `opal_timer_windows_open': timer_windows_component.c:60: error: `LARGE_INTEGER' undeclared (first use in this function) timer_windows_component.c:60: error: (Each undeclared identifier is reported only once timer_windows_component.c:60: error: for each function it appears in.) timer_windows_component.c:60: error: parse error before "now" timer_windows_component.c:62: error: `now' undeclared (first use in this function) make[2]: *** [timer_windows_component.lo] Error 1 make[2]: Leaving directory `/home/seabra/local/openmpi-1.2.7/opal/mca/timer/windows' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/seabra/local/openmpi-1.2.7/opal' make: *** [install-recursive] Error 1
Re: [OMPI users] Fwd: Problems installing in Cygwin
On Tue, Oct 28, 2008 at 9:06 AM, George Bosilca wrote: > It is complaining about a missing file. This is a file from the Open MPI > distribution, I wonder how it can be missing. Can you verify that the file > opal/mca/timer/windows/timer_windows_component.h is there ? No, it's not. But I see a opal/mca/timer/windows/timer_windows_component.c and a timer_windows.h there. Should it have been generated at some point in the compilation? The contents of that directory are only: $ ls $HOME/local/openmpi-1.2.7/opal/mca/timer/windows/ Makefile Makefile.am Makefile.in configure.m4 timer_windows.h timer_windows_component.c I don't know how relevant it is, but I downloaded the "openmpi-1.2.7.tar.bz2" file (MD5SUM b5ae3059fba71eba4a89a2923da8223f). Also, I'm trying to make a local install, in $HOME/local/openmpi-1.2.7. Finally, as I may have mentioned before, this installation is in Cygwin but, as far as I understand, it shouldn't matter much since Cygwin these days can reproduce a POSIX environment very well. Also, I don't quite understand why is it looking for what it seems (to me) to be windows-based function, since it is in a POSIX environment. Thank you very much. Please let me know if there is any other information I can provide to help track this. All the best, -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA
Re: [OMPI users] Fwd: Problems installing in Cygwin
On Mon, Oct 27, 2008 at 4:52 PM, Jeff Squyres wrote: > Sorry for the lack of reply; several of us were at the MPI Forum meeting > last week, and although I can't speak for everyone else, I know that I > always fall [way] behind on e-mail when I travel. :-\ > > The windows port is very much a work-in-progress. I'm not surprised that it > doesn't work. :-\ > > The good folks at U. Stuttgart/HLRS are actively working on a real Windows > port, but it's off in a side-branch right now. I don't know the exact > status of this port -- George / Rainer / Shiqing, can you comment? Hi Jeff, Thanks a lot for your interest. I just wanted to clarify that I am *not* looking for a Windows port. I'm actually trying to compile it in Cygwin, which *should* behave like a regular *nix system, so that issue should *not* be specific of windows systems. If it turns out to be a "happens-in-windows-cygwin-only" thing, then it is most likely coming from some problem with my Cygwin installation, or (unlikely) a Cygwin bug. Thanks, Gustavo.
Re: [OMPI users] Fwd: Problems installing in Cygwin
On Wed, Oct 29, 2008 at 10:48 AM, George Bosilca wrote: > Gustavo, > > I think we have a problem in the "make dist" for the 1.2. I just downloaded > the latest 1.2.8, and the windows timer component header file is not in the > tarball. This file is not automatically generated, and it is in the svn > version. > > Anyway, the 1.3 is nearly ready to replace the 1.2 as the stable version. > And it does have this file, so I strongly suggest to switch from the 1.2 to > the 1.3 series. Hi George, Thank you very much for the suggestion. I did what you suggested and downloaded openmpi-1.3b1, and now I can see that file there. The configuration ends cleanly again, but this time the compilation stops with the error below. Do you mind taking a look at it to see what could be wrong? Thanks. = [...] Making install in mca/memory/mallopt make[2]: Entering directory `/home/seabra/local/openmpi-1.3b1/opal/mca/memory/mallopt' depbase=`echo memory_mallopt_component.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT memory_mallopt_component.lo -MD -MP -MF $depbase.Tpo -c -o memory_mallopt_component.lo memory_mallopt_component.c &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT memory_mallopt_component.lo -MD -MP -MF .deps/memory_mallopt_component.Tpo -c memory_mallopt_component.c -DDLL_EXPORT -DPIC -o .libs/memory_mallopt_component.o memory_mallopt_component.c: In function `munmap': memory_mallopt_component.c:106: error: `RTLD_NEXT' undeclared (first use in this function) memory_mallopt_component.c:106: error: (Each undeclared identifier is reported only once memory_mallopt_component.c:106: error: for each function it appears in.) make[2]: *** [memory_mallopt_component.lo] Error 1 make[2]: Leaving directory `/home/seabra/local/openmpi-1.3b1/opal/mca/memory/mallopt' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/seabra/local/openmpi-1.3b1/opal' make: *** [install-recursive] Error =
Re: [OMPI users] Fwd: Problems installing in Cygwin
On Wed, Oct 29, 2008 at 1:49 PM, Jeff Squyres wrote: > Ugh. IMHO, Cygwin != POSIX. > > The problem is that we're making the assumption that if dlsym() is present, > RTLD_NEXT is defined. I guess that's not true for cygwin (lame). I suppose > that we could also check for RTLD_NEXT...? Is there any other OS where > dlsym() is present by RTLD_NEXT is not? > > Would it be easier to run Linux in a virtual machine on your windows host? > You'll probably get a lot better performance...? Hi Jeff, Are you sure RTLD_NEXT is part of the POSIX standard? I may be looking in the wrong place, but apparently it is *not* part of the standard, at least as defined here: http://www.opengroup.org/onlinepubs/95399/basedefs/dlfcn.h.html It would seem that this is a GNU extension, so it becomes available when __USE_GNU is defined. Now, looking at the cygwin version of dlfcn.h, I see that RTDL_NEXT is *not* defined, but RTDL_LAZY, RTLD_NOW, RTLD_LOCAL and RTLD_GLOBAL, which makes it compliant with POSIX, but not GNU. The 'memory_mallopt_component.c' only checks if 'HAVE_DLSYM' is defined. If so, it defines __USE_GNU then includes dlfcn.h. This is ok, assuming you have a GNU version of dlfcn.h, but apparently this is not present in Cygwin... So far, apparently, CYGWIN == POSIX (still), but CYGWIN != GNU. -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA
Re: [OMPI users] Fwd: Problems installing in Cygwin
On Thu, Oct 30, 2008 at 8:40 AM, Jeff Squyres wrote: > On Oct 29, 2008, at 4:31 PM, Gustavo Seabra wrote: > >>> Ugh. IMHO, Cygwin != POSIX. >>> >>> The problem is that we're making the assumption that if dlsym() is >>> present, >>> RTLD_NEXT is defined. I guess that's not true for cygwin (lame). I >>> suppose >>> that we could also check for RTLD_NEXT...? Is there any other OS where >>> dlsym() is present by RTLD_NEXT is not? >>> >>> Would it be easier to run Linux in a virtual machine on your windows >>> host? >>> You'll probably get a lot better performance...? >> >> Hi Jeff, >> >> Are you sure RTLD_NEXT is part of the POSIX standard? I may be looking >> in the wrong place, but apparently it is *not* part of the standard, >> at least as defined here: >> >> http://www.opengroup.org/onlinepubs/95399/basedefs/dlfcn.h.html > > Fair enough -- my words were ambiguous, and probably overly broad. I was > trying to convey that my prior experience with Cygwin has biased me to > believe that Cygwin tends to be "different" than other POSIX-like OSs, such > as Linux, Solaris, and OS X. > >> It would seem that this is a GNU extension, so it becomes available >> when __USE_GNU is defined. Now, looking at the cygwin version of >> dlfcn.h, I see that RTDL_NEXT is *not* defined, but RTDL_LAZY, >> RTLD_NOW, RTLD_LOCAL and RTLD_GLOBAL, which makes it compliant with >> POSIX, but not GNU. >> >> The 'memory_mallopt_component.c' only checks if 'HAVE_DLSYM' is >> defined. If so, it defines __USE_GNU then includes dlfcn.h. This is >> ok, assuming you have a GNU version of dlfcn.h, but apparently this is >> not present in Cygwin... > > Understood; this was a more complete/precise meaning for my question "Is > there any other OS where > dlsym() is present by RTLD_NEXT is not?" I suppose we can extend the > configure test to check for RTLD_NEXT as well. In this way, that component > won't even decide to build itself. You won't need this component, because > it's only really useful for the OpenFabrics and [ancient] Myricom GM drivers > in Open MPI, neither of which are likely to be supported in Cygwin. That should be good enough, at least for that part. Or testing first for the presence of OpenFabrics or Myricom? Maybe it could just test for the existence of GNU extensions? I don't know. I understand it must be really hard to keep track of what is standard and what is not these days. I'm just thankful that you guys are looking into it. Thanks! > Also FWIW, my understanding is that running another OS in a VM (such as > Linux or your favorite BSD) will run *much* faster than Cygwin. I have dim > recollections of LAM's and OMPI's "configure" script taking loong > periods of time (I no longer have easy access to a Windows machine to do > such testing). Those with more Windows experience than me attributed it to > Windows' process model implementation, which is quite different than > Linux/Solaris/OSX/etc. So I'm just curious: do you have a reason for > preferring Cygwin instead of a VM? Well... I don't. It's just that, due to specifics of my work, I need to work on a Windows computer, but I also like to use many unix features / commands. So, I just use Cygwin out of convenience, which in a way gives me the best of both worlds without the need to dual boot. However, the other reason I use Cygwin is because I work in the development of a program and it is very convenient to do that in Cygwin, especially when I'm traveling and only have access to my laptop. Many users have this program running in Cygwin, so it's also good to have a place to test it. I don't really use Cygwin for the long "production" runs that would actually require a MPI, for that I have access to local clusters or Teragrid. My problem is testing the parallel version in Cygwin (or if any changes made break the parallel implementation) because I still did not manage to install a MPI in Cygwin. In fact, I have never tried a VM :-$ I guess I should give it a try sometime. Do you have any recommendations? My only requirements are that (i) it works, (ii) it's free. Thanks a lot!! -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA
Re: [OMPI users] Fwd: Problems installing in Cygwin
As I keep trying to install OpenMPI in Cygwin, I found another instance where RTFD_NEXT is assumed to be present. Will keep trying... Gustavo. = Making all in vtlib make[5]: Entering directory `/home/seabra/local/openmpi-1.3b1/ompi/contrib/vt/vt/vtlib' gcc -DHAVE_CONFIG_H -I. -I.. -I../tools/opari/lib -I../extlib/otf/otflib -I../extlib/otf/otflib -D_REENTRANT -DBINDIR=\"/home/seabra/local/openmpi-1.3b1/bin\" -DDATADIR=\"/home/seabra/local/openmpi-1.3b1/share/vampirtrace\" -DRFG -DVT_BFD -DVT_IOWRAP -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT vt_comp_gnu.o -MD -MP -MF .deps/vt_comp_gnu.Tpo -c -o vt_comp_gnu.o vt_comp_gnu.c mv -f .deps/vt_comp_gnu.Tpo .deps/vt_comp_gnu.Po gcc -DHAVE_CONFIG_H -I. -I.. -I../tools/opari/lib -I../extlib/otf/otflib -I../extlib/otf/otflib -D_REENTRANT -DBINDIR=\"/home/seabra/local/openmpi-1.3b1/bin\" -DDATADIR=\"/home/seabra/local/openmpi-1.3b1/share/vampirtrace\" -DRFG -DVT_BFD -DVT_IOWRAP -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT vt_iowrap.o -MD -MP -MF .deps/vt_iowrap.Tpo -c -o vt_iowrap.o vt_iowrap.c vt_iowrap.c: In function `vt_iowrap_init': vt_iowrap.c:105: error: `RTLD_NEXT' undeclared (first use in this function) vt_iowrap.c:105: error: (Each undeclared identifier is reported only once vt_iowrap.c:105: error: for each function it appears in.) vt_iowrap.c: In function `open': vt_iowrap.c:188: error: `RTLD_NEXT' undeclared (first use in this function) [...and a bunch of messages just like those last 2 lines...]
Re: [OMPI users] Fwd: Problems installing in Cygwin
On Thu, Oct 30, 2008 at 9:04 AM, George Bosilca wrote: Hi George, I'm sorry for taking too long to respond. As you mentioned, config takes a veeery long time in cygwin, and then the install itself takes many ties that :-( > As Jeff mentioned this component is not required on Windows. You can disable > it completely in Open MPI and everything will continue to work correctly. > Please add --enable-mca-no-build=memory_mallopt o maybe the more generic (as > there is no need for any memory manager on Windows > --enable-mca-no-build=memory. Tried, doesn't quite work: If I configure with "--enable-mca-no-build=memory", the config dies with: *** Final output configure: error: conditional "OMPI_WANT_EXTERNAL_PTMALLOC2" was never defined. Usually this means the macro was only invoked conditionally. Now, if i try with "--enable-mca-no-build=memory_mallopt", the configuration script runs just fine, but the compilation dies when compiling "mca/paffinity/windows": libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../.. /ompi/include -I../../../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../.. -D_REENTRANT -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -MT paffinity_windows_module.lo -MD -MP -MF .deps/paffinity_windows_module.Tpo -c paffinity_windows_module.c -DDLL_EXPORT -DPIC -o .libs/paffinity_windows_module.o paffinity_windows_module.c:44: error: parse error before "sys_info" [... and then a bunch of messages after that, all related to paffinity_windows_module.c, which...] [... I think are all related to this first one...] Finally, I thought that I can live without processor affinity or even memory affinity, so I tried using " --enable-mca-no-build=memory_mallopt,maffinity,paffinity", and the configuration went all smoothly. The compilation... You guessed, died again. But this time it was something that had bit me before: RTLD_NEXT, which is required by one contributed package (vt). (See my previous message to Jeff and the list.) My next attempt will be to remove this package, and see how far I can get... But I'm getting there :-) > It is possible to have a native version of Open MPI on Windows. There are > two ways to achieve this. First, install SFU, and compile there. It worked > last time I checked, but it's not the solution I prefer. Second, you can > install the express version of the Microsoft Visual Studio (which is free), > and set your PATH, LIB and INCLUDE correctly to point to the installation, > and then you can use the cl compiler to build Open MPI even on Windows. That is true, but it seems more complicated for the regular user than installing OpenMPI (assuming I can figure out the correct combination of options) Also, our program is actually made for unix, and as a convenience it *can* be installed in Cygwin, but I'm not sure how it would work with a native Windows OpenMPI. Anyways... I fell like I'm getting closer.. Will keep trying during the weekend. Thanks a lot for all the help! (That goes to Jeff too) Cheers, Gustavo.
Re: [OMPI users] MPI + Mixed language coding(Fortran90 + C++)
On Fri, Oct 31, 2008 at 3:07 PM, Rajesh Ramaya wrote: > Actually I am > not writing any MPI code inside? It's the executable (third party software) > who does that part. What are you using for this? We too use Fortran and C routines combined with no problem at all. I would think that whatever "third-party" software you are using here is not doing its job right. -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA
[OMPI users] Problems installing in Cygwin - Problem with GCC 3.4.4
_ForwardIterator,
_ForwardIterator, std::forward_iterator_tag)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522:
error: expected unqualified-id before '(' token
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In
member function `void std::vector::_M_fill_insert(std::_Bit_iterator, size_t, bool)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823:
error: expected unqualified-id before '(' token
In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:75,
from ../../../ompi/tools/ompi_info/ompi_info.h:24,
from param.cc:43:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In
member function `void std::vector<_Tp,
_Alloc>::_M_fill_insert(__gnu_cxx::__normal_iterator >, size_t, const _Tp&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307:
error: expected unqualified-id before '(' token
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In
member function `void std::vector<_Tp,
_Alloc>::_M_range_insert(__gnu_cxx::__normal_iterator >, _ForwardIterator,
_ForwardIterator, std::forward_iterator_tag)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384:
error: expected unqualified-id before '(' token
--
Gustavo Seabra
Postdoctoral Associate
Quantum Theory Project - University of Florida
Gainesville - Florida - USA
Re: [OMPI users] Problems installing in Cygwin - Problem with GCC 3.4.4
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.
Re: [OMPI users] Problems installing in Cygwin - Problem with GCC 3.4.4
On Mon, Nov 3, 2008 at 8:59 PM, Terry Frankcombe wrote: >> On Nov 3, 2008, at 3:36 PM, Gustavo Seabra wrote: >> >>>> 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)? >> >> Ah yes -- that's another reason the f90 interface could be disabled: >> if configure detects that the f77 and f90 compilers are not link- >> compatible. >> >>> I thought the g95 compiler could >>> deal with F77 as well as F95... If so, could I just pass F77='g95'? >> >> That would probably work (F77=g95). I don't know the g95 compiler at >> all, so I don't know if it also accepts Fortran-77-style codes. But >> if it does, then you're set. Otherwise, specify a different F77 >> compiler that is link compatible with g95 and you should be good. > > Fortran 90 is a superset of the archaic, hamstrung, "I'm too old to learn > how to program in a useful manner and I still use punched cards" Fortran > 77. All Fortran 90 compilers are Fortran 77 compilers, by definition. > Fortran 95 has a few (~5) deleted features and a few minor added features. > I've never heard of a Fortran 95 compiler that wasn't a Fortran 90 > compiler, and thus a Fortran 77 compiler. > > Take g77 and throw it away. While it's not particularly buggy, it hasn't > been maintained for years and should be out-performed by a more modern > compiler such as g95 or gfortran. > OK, so I tried to set all my fortran compilers to g95... But for some reason, it looks like g95 and g95 (!) compilers are not compatible... How's that even possible? (See below) Thanks a lot, Gustavo. -- ./configure --prefix=$MPI_HOME \ --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' F77='g95' F90='g95' F95='g95' \ CC='gcc' CXX='g++' \ FFLAGS='-O0 -fno-second-underscore' *** Fortran 77 compiler checking whether we are using the GNU Fortran 77 compiler... yes checking whether g95 accepts -g... yes checking if Fortran 77 compiler works... yes checking g95 external symbol convention... single underscore checking if C and Fortran 77 are link compatible... yes (just a ton of "yes"-es) *** 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 g95 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
Re: [OMPI users] openmpi-1.2.8 and cygwin...
Is that going to work with Cygwin programs? One reason I have been trying to install OpenMPI in Cygwin is to be able to run Cygwin programs in parallel. Would a native Windows implementation help there? Gustavo. On Tue, Nov 18, 2008 at 4:45 AM, Shiqing Fan wrote: > Dear Solibakke, > > I'm not familiar with the installation under Cygwin, but what I can tell is > that we are making a windows support public very soon. When it's ready, you > will never need to install Open MPI under Cygwin on Windows, you will be > able to configure with CMake and compile everything with Visual Studio > (2005/2008/Express), or you could also install Open MPI with a binary > installer without compiling any source code. > > I suggest you to use Open MPI trunk when the Windows support (with CMake) is > ready. I'm also glad to help you with that. > > > Regards, > Shiqing > > > Solibakke Per Bjarte wrote: >> >> I'm trying to use CYGWIN + Open-mpi 1.2.8 / open-mpi-1.3b2 >> /openmpi-1.4a1r20006 >> In all o+pen-mpi versions I receive the following error messege from >> make all (see attached file: /log.make/) >> The configure works well: >> ./configure --prefix=/usr/local/ompi-1-2-8 --with-mpi-param-check=runtime >> --with-threads=posix --enable-mpi-threads --disable-io-romio >> --enable-mca-no-build=memory_mallopt,maffinity,paffinity >> --enable-contrib-no-build=vt --enable-shared >> Is this a bug in open-mpi-2.8 or is there something missing from CYGWIN >> installation? >> Reagards >> PBSolibakke
