Re: [OMPI users] users Digest, Vol 3592, Issue 1

[Gilles Gouaillardet]

Sam,


openmpi-devel-1.7.3-1.fc20 rpm provides

/usr/lib64/openmpi/bin/mpicc


this is the mpicc you want to use to build mpi4py


of course, you can download and install a recent Open MPI version from 
open-mpi.org.
if you decide to go this way, i recommend you download 1.10.3 from 
https://www.open-mpi.org/software/ompi/v1.10/


Cheers,

Gilles

On 9/1/2016 3:20 AM, Mahdi, Sam wrote:


To dave, from the installation guide I found, it seemed I couldnt just 
directly download it from the package list, but rather Id need to use 
the mpicc wrapper to compile and install. I also wanted to see if I 
could build it from the installation guide, sorta learn how the whole 
process worked.


To guilles, do I need to download open mpi directly from the site to 
obtain the mpicc and to get the current version?


Thank you both for your responces


On Aug 31, 2016 11:00 AM, > wrote:


Send users mailing list submissions to
users@lists.open-mpi.org 

To subscribe or unsubscribe via the World Wide Web, visit
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

or, via email, send a message with subject or body 'help' to
users-requ...@lists.open-mpi.org


You can reach the person managing the list at
users-ow...@lists.open-mpi.org 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. Re: Certain files for mpi missing when building mpi4py
  (Gilles Gouaillardet)
   2. Re: Certain files for mpi missing when building mpi4py (Dave
Love)


--

Message: 1
Date: Wed, 31 Aug 2016 11:22:23 +0900
From: Gilles Gouaillardet mailto:gil...@rist.or.jp>>
To: Open MPI Users mailto:users@lists.open-mpi.org>>
Subject: Re: [OMPI users] Certain files for mpi missing when building
mpi4py
Message-ID: <1fb7e491-be43-c59c-07d4-5890f6793...@rist.or.jp
>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Sam,

at first you mentionned Open MPI 1.7.3.

though this is now a legacy version, you posted to the right place.


then you

# python setup.py build --mpicc=/usr/lib64/mpich/bin/mpicc


this is mpich, which is a very reputable MPI implementation, but not
Open MPI.

so i do invite you to use Open MPI mpicc, and try again.


Cheers,


Gilles


PS

with Open MPI, you can

mpirun -showme ...

in order to display how the compiler (e.g. gcc) is invoked

with mpich, that would be (there might be a better option i am
unaware of)

mpirun -v ...

if mpich mpicc wrapper is not broken, it should include a path to
mpi.h

(e.g. -I/usr/lib64/mpich/include)

and unless a package is missing (mpich-devel ?), that file should
exist


you cannot use Open MPI mpi.h with mpich, nor the other way
around, and
you should not copy this file to an other place

(that should not be needed at all)

On 8/31/2016 4:22 AM, Mahdi, Sam wrote:
> HI everyone,
>
> I am using a linux fedora. I downloaded/installed
> openmpi-1.7.3-1.fc20(64-bit) and openmpi-devel-1.7.3-1.fc20(64-bit).
> As well as pypar-openmpi-2.1.5_108-3.fc20(64-bit) and
> python3-mpi4py-openmpi-1.3.1-1.fc20(64-bit). The problem I am having
> is building mpi4py using the mpicc wrapper. I have installed and
> untarred mpi4py from
https://pypi.python.org/pypi/mpi4py#downloads
. I
> went to compile it and received this error. I typed in
> python setup.py build --mpicc=/usr/lib64/mpich/bin/mpicc
> This was the output
> running build
> running build_src
> running build_py
> running build_clib
> MPI configuration: [mpi] from 'mpi.cfg'
> MPI C compiler:/usr/lib64/mpich/bin/mpicc
> running build_ext
> MPI configuration: [mpi] from 'mpi.cfg'
> MPI C compiler:/usr/lib64/mpich/bin/mpicc
> checking for MPI compile and link ...
> /usr/lib64/mpich/bin/mpicc -pthread -fno-strict-aliasing -O2 -g
-pipe
> -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
> -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python2.7 -c
> _configtest.c -o _configtest.o
> _configtest.c:2:17: fatal error: mpi.h: No such file or directory
  

[OMPI users] mpi4py/fc20 (was: users Digest, Vol 3592, Issue 1)

[Dave Love]

"Mahdi, Sam"  writes:

> To dave, from the installation guide I found, it seemed I couldnt just
> directly download it from the package list, but rather Id need to use the
> mpicc wrapper to compile and install.

That makes no sense to a maintainer of some openmpi Fedora packages, and
I actually have mpi4py-openmpi installed and working from EPEL6.

> I also wanted to see if I could build
> it from the installation guide, sorta learn how the whole process worked.

Well, the spec file tells you how to build on the relevant version of
Fedora, including the dependencies.

> To guilles, do I need to download open mpi directly from the site to obtain
> the mpicc and to get the current version?

You said you already have the openmpi-devel package, which is what
provides it.

I really wouldn't run f20 on a typical HPC system, though.
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Jeff Squyres (jsquyres)]

Greetings Sean.

Yes, you are correct - when you build from the tarball, you should not need the 
GNU autotools.

When tarball builds fail like this, it *usually* means that you are building in 
a network filesystem, and the time is not well synchronized between the machine 
on which you are building and the network filesystem server.  Specifically: GNU 
Autotools-based builds are heavily dependent upon filesystem timestamps.  If 
the sync is off between a network filesystem client and server, all kinds of 
things go wrong (to include thinking that it needs to run the autotools as part 
of the build).



> On Sep 1, 2016, at 11:47 AM, Sean Ahern  wrote:
> 
> I'm trying to compile OpenMPI 2.0.0 on a CentOS 6.7 system and am running 
> into what appears to be a very basic problem. I'm hoping someone here can 
> give me a pointer. (I'll have more involved questions later.)​ ​I've looked 
> through the FAQ for an answer and didn't see anything related. And I don't 
> see any messages in the archives from the last several years about this.
> 
> I'm using the tarball 2.0.0 release, which presumably shouldn't require the 
> GNU autotools. But, after running "configure", the subsequent "make" fails, 
> trying to run aclocal-1.15​.
> 
> Here's running configure:​
> 
> % ./configure --prefix=blah/blah/openmpi-2.0.0 --disable-java 
> --disable-mpi-fortran
> 
> == Configuring Open MPI
> 
> 
> *** Startup tests
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> … lots of output …
> config.status: creating ompi/mpiext/cuda/c/mpiext_cuda_c.h
> config.status: ompi/mpiext/cuda/c/mpiext_cuda_c.h is unchanged
> config.status: executing depfiles commands
> config.status: executing 
> opal/mca/event/libevent2022/libevent/include/event2/event-config.h commands
> config.status: executing libtool commands
> 
> Seems fine. (If someone wants the full "configure" output, I'll send it.)
> But when I run "make", I immediately get this:
> 
> % make all
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
> /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing 
> aclocal-1.15 -I config
> /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing: line 
> 81: aclocal-1.15: command not found
> WARNING: 'aclocal-1.15' is missing on your system.
>  You should only need it if you modified 'acinclude.m4' or
>  'configure.ac' or m4 files included by 'configure.ac'.
>  The 'aclocal' program is part of the GNU Automake package:
>  
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>  
>  
>  
> make: *** [aclocal.m4] Error 127
> 
> I haven't modified any m4 files. Indeed, I haven't modified anything. I 
> simply ran "configure" and then "make". What am I doing wrong? I feel like 
> there's something very basic failing here.
> 
> (I have attached my bzip2ed config.log file here.)
> 
> ​-Sean
> 
> --
> Sean Ahern
> Computational Engineering International
> 919-363-0883
> ___
> users mailing list
> users@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/users


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Sean Ahern]

Greetings, Jeff.

Sure, I could see that. But I'm trying to run on a locally mounted
filesystem in this case. I may need to run make in debug mode and see what
it thinks is out of date. See if you guys can help me track down the
dependency problem.

-Sean

--
Sean Ahern
Computational Engineering International
919-363-0883

On Thu, Sep 1, 2016 at 11:56 AM, Jeff Squyres (jsquyres)  wrote:

> Greetings Sean.
>
> Yes, you are correct - when you build from the tarball, you should not
> need the GNU autotools.
>
> When tarball builds fail like this, it *usually* means that you are
> building in a network filesystem, and the time is not well synchronized
> between the machine on which you are building and the network filesystem
> server.  Specifically: GNU Autotools-based builds are heavily dependent
> upon filesystem timestamps.  If the sync is off between a network
> filesystem client and server, all kinds of things go wrong (to include
> thinking that it needs to run the autotools as part of the build).
>
>
>
> > On Sep 1, 2016, at 11:47 AM, Sean Ahern  wrote:
> >
> > I'm trying to compile OpenMPI 2.0.0 on a CentOS 6.7 system and am
> running into what appears to be a very basic problem. I'm hoping someone
> here can give me a pointer. (I'll have more involved questions later.)​
> ​I've looked through the FAQ for an answer and didn't see anything related.
> And I don't see any messages in the archives from the last several years
> about this.
> >
> > I'm using the tarball 2.0.0 release, which presumably shouldn't require
> the GNU autotools. But, after running "configure", the subsequent "make"
> fails, trying to run aclocal-1.15​.
> >
> > Here's running configure:​
> >
> > % ./configure --prefix=blah/blah/openmpi-2.0.0 --disable-java
> --disable-mpi-fortran
> > 
> 
> > == Configuring Open MPI
> > 
> 
> >
> > *** Startup tests
> > checking build system type... x86_64-unknown-linux-gnu
> > checking host system type... x86_64-unknown-linux-gnu
> > checking target system type... x86_64-unknown-linux-gnu
> > checking for gcc... gcc
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables...
> > checking whether we are cross compiling... no
> > … lots of output …
> > config.status: creating ompi/mpiext/cuda/c/mpiext_cuda_c.h
> > config.status: ompi/mpiext/cuda/c/mpiext_cuda_c.h is unchanged
> > config.status: executing depfiles commands
> > config.status: executing opal/mca/event/libevent2022/
> libevent/include/event2/event-config.h commands
> > config.status: executing libtool commands
> >
> > Seems fine. (If someone wants the full "configure" output, I'll send it.)
> > But when I run "make", I immediately get this:
> >
> > % make all
> > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/sean/work/thirdparty/
> trunk/OpenMPI/openmpi-2.0.0/config/missing aclocal-1.15 -I config
> > /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing:
> line 81: aclocal-1.15: command not found
> > WARNING: 'aclocal-1.15' is missing on your system.
> >  You should only need it if you modified 'acinclude.m4' or
> >  'configure.ac' or m4 files included by 'configure.ac'.
> >  The 'aclocal' program is part of the GNU Automake package:
> >  
> >  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> >  
> >  
> >  
> > make: *** [aclocal.m4] Error 127
> >
> > I haven't modified any m4 files. Indeed, I haven't modified anything. I
> simply ran "configure" and then "make". What am I doing wrong? I feel like
> there's something very basic failing here.
> >
> > (I have attached my bzip2ed config.log file here.)
> >
> > ​-Sean
> >
> > --
> > Sean Ahern
> > Computational Engineering International
> > 919-363-0883
> > ___
> > users mailing list
> > users@lists.open-mpi.org
> > https://rfd.newmexicoconsortium.org/mailman/listinfo/users
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: http://www.cisco.com/web/
> about/doing_business/legal/cri/
>
> ___
> users mailing list
> users@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/users
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Jeff Squyres (jsquyres)]

That's odd -- I've never seen this kind of problem happen on a locally-mounted 
filesystem.

Just to make sure: you're *not* running autogen.pl, right?  You're just 
basically doing this:

-
$ tar xf openmpi-2.0.0.tar.bz2
$ cd openmpi-2.0.0
$ ./configure ...
$ make ...
-

Right?


> On Sep 1, 2016, at 12:51 PM, Sean Ahern  wrote:
> 
> Greetings, Jeff.
> 
> Sure, I could see that. But I'm trying to run on a locally mounted filesystem 
> in this case. I may need to run make in debug mode and see what it thinks is 
> out of date. See if you guys can help me track down the dependency problem.
> 
> -Sean
> 
> --
> Sean Ahern
> Computational Engineering International
> 919-363-0883
> 
> On Thu, Sep 1, 2016 at 11:56 AM, Jeff Squyres (jsquyres)  
> wrote:
> Greetings Sean.
> 
> Yes, you are correct - when you build from the tarball, you should not need 
> the GNU autotools.
> 
> When tarball builds fail like this, it *usually* means that you are building 
> in a network filesystem, and the time is not well synchronized between the 
> machine on which you are building and the network filesystem server.  
> Specifically: GNU Autotools-based builds are heavily dependent upon 
> filesystem timestamps.  If the sync is off between a network filesystem 
> client and server, all kinds of things go wrong (to include thinking that it 
> needs to run the autotools as part of the build).
> 
> 
> 
> > On Sep 1, 2016, at 11:47 AM, Sean Ahern  wrote:
> >
> > I'm trying to compile OpenMPI 2.0.0 on a CentOS 6.7 system and am running 
> > into what appears to be a very basic problem. I'm hoping someone here can 
> > give me a pointer. (I'll have more involved questions later.)​ ​I've looked 
> > through the FAQ for an answer and didn't see anything related. And I don't 
> > see any messages in the archives from the last several years about this.
> >
> > I'm using the tarball 2.0.0 release, which presumably shouldn't require the 
> > GNU autotools. But, after running "configure", the subsequent "make" fails, 
> > trying to run aclocal-1.15​.
> >
> > Here's running configure:​
> >
> > % ./configure --prefix=blah/blah/openmpi-2.0.0 --disable-java 
> > --disable-mpi-fortran
> > 
> > == Configuring Open MPI
> > 
> >
> > *** Startup tests
> > checking build system type... x86_64-unknown-linux-gnu
> > checking host system type... x86_64-unknown-linux-gnu
> > checking target system type... x86_64-unknown-linux-gnu
> > checking for gcc... gcc
> > checking whether the C compiler works... yes
> > checking for C compiler default output file name... a.out
> > checking for suffix of executables...
> > checking whether we are cross compiling... no
> > … lots of output …
> > config.status: creating ompi/mpiext/cuda/c/mpiext_cuda_c.h
> > config.status: ompi/mpiext/cuda/c/mpiext_cuda_c.h is unchanged
> > config.status: executing depfiles commands
> > config.status: executing 
> > opal/mca/event/libevent2022/libevent/include/event2/event-config.h commands
> > config.status: executing libtool commands
> >
> > Seems fine. (If someone wants the full "configure" output, I'll send it.)
> > But when I run "make", I immediately get this:
> >
> > % make all
> > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
> > /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing 
> > aclocal-1.15 -I config
> > /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing: line 
> > 81: aclocal-1.15: command not found
> > WARNING: 'aclocal-1.15' is missing on your system.
> >  You should only need it if you modified 'acinclude.m4' or
> >  'configure.ac' or m4 files included by 'configure.ac'.
> >  The 'aclocal' program is part of the GNU Automake package:
> >  
> >  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> >  
> >  
> >  
> > make: *** [aclocal.m4] Error 127
> >
> > I haven't modified any m4 files. Indeed, I haven't modified anything. I 
> > simply ran "configure" and then "make". What am I doing wrong? I feel like 
> > there's something very basic failing here.
> >
> > (I have attached my bzip2ed config.log file here.)
> >
> > ​-Sean
> >
> > --
> > Sean Ahern
> > Computational Engineering International
> > 919-363-0883
> > ___
> > users mailing list
> > users@lists.open-mpi.org
> > https://rfd.newmexicoconsortium.org/mailman/listinfo/users
> 
> 
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> users mailing list
> users@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/list

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Sean Ahern]

Yep, that's it.
-Sean

--
Sean Ahern
Computational Engineering International
919-363-0883


On Thu, Sep 1, 2016 at 1:04 PM, Jeff Squyres (jsquyres)
 wrote:
> That's odd -- I've never seen this kind of problem happen on a 
> locally-mounted filesystem.
>
> Just to make sure: you're *not* running autogen.pl, right?  You're just 
> basically doing this:
>
> -
> $ tar xf openmpi-2.0.0.tar.bz2
> $ cd openmpi-2.0.0
> $ ./configure ...
> $ make ...
> -
>
> Right?
>
>
>> On Sep 1, 2016, at 12:51 PM, Sean Ahern  wrote:
>>
>> Greetings, Jeff.
>>
>> Sure, I could see that. But I'm trying to run on a locally mounted 
>> filesystem in this case. I may need to run make in debug mode and see what 
>> it thinks is out of date. See if you guys can help me track down the 
>> dependency problem.
>>
>> -Sean
>>
>> --
>> Sean Ahern
>> Computational Engineering International
>> 919-363-0883
>>
>> On Thu, Sep 1, 2016 at 11:56 AM, Jeff Squyres (jsquyres) 
>>  wrote:
>> Greetings Sean.
>>
>> Yes, you are correct - when you build from the tarball, you should not need 
>> the GNU autotools.
>>
>> When tarball builds fail like this, it *usually* means that you are building 
>> in a network filesystem, and the time is not well synchronized between the 
>> machine on which you are building and the network filesystem server.  
>> Specifically: GNU Autotools-based builds are heavily dependent upon 
>> filesystem timestamps.  If the sync is off between a network filesystem 
>> client and server, all kinds of things go wrong (to include thinking that it 
>> needs to run the autotools as part of the build).
>>
>>
>>
>> > On Sep 1, 2016, at 11:47 AM, Sean Ahern  wrote:
>> >
>> > I'm trying to compile OpenMPI 2.0.0 on a CentOS 6.7 system and am running 
>> > into what appears to be a very basic problem. I'm hoping someone here can 
>> > give me a pointer. (I'll have more involved questions later.) I've looked 
>> > through the FAQ for an answer and didn't see anything related. And I don't 
>> > see any messages in the archives from the last several years about this.
>> >
>> > I'm using the tarball 2.0.0 release, which presumably shouldn't require 
>> > the GNU autotools. But, after running "configure", the subsequent "make" 
>> > fails, trying to run aclocal-1.15.
>> >
>> > Here's running configure:
>> >
>> > % ./configure --prefix=blah/blah/openmpi-2.0.0 --disable-java 
>> > --disable-mpi-fortran
>> > 
>> > == Configuring Open MPI
>> > 
>> >
>> > *** Startup tests
>> > checking build system type... x86_64-unknown-linux-gnu
>> > checking host system type... x86_64-unknown-linux-gnu
>> > checking target system type... x86_64-unknown-linux-gnu
>> > checking for gcc... gcc
>> > checking whether the C compiler works... yes
>> > checking for C compiler default output file name... a.out
>> > checking for suffix of executables...
>> > checking whether we are cross compiling... no
>> > … lots of output …
>> > config.status: creating ompi/mpiext/cuda/c/mpiext_cuda_c.h
>> > config.status: ompi/mpiext/cuda/c/mpiext_cuda_c.h is unchanged
>> > config.status: executing depfiles commands
>> > config.status: executing 
>> > opal/mca/event/libevent2022/libevent/include/event2/event-config.h commands
>> > config.status: executing libtool commands
>> >
>> > Seems fine. (If someone wants the full "configure" output, I'll send it.)
>> > But when I run "make", I immediately get this:
>> >
>> > % make all
>> > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
>> > /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing 
>> > aclocal-1.15 -I config
>> > /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing: 
>> > line 81: aclocal-1.15: command not found
>> > WARNING: 'aclocal-1.15' is missing on your system.
>> >  You should only need it if you modified 'acinclude.m4' or
>> >  'configure.ac' or m4 files included by 'configure.ac'.
>> >  The 'aclocal' program is part of the GNU Automake package:
>> >  
>> >  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>> >  
>> >  
>> >  
>> > make: *** [aclocal.m4] Error 127
>> >
>> > I haven't modified any m4 files. Indeed, I haven't modified anything. I 
>> > simply ran "configure" and then "make". What am I doing wrong? I feel like 
>> > there's something very basic failing here.
>> >
>> > (I have attached my bzip2ed config.log file here.)
>> >
>> > -Sean
>> >
>> > --
>> > Sean Ahern
>> > Computational Engineering International
>> > 919-363-0883
>> > ___
>> > users mailing list
>> > users@lists.open-mpi.org
>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/users
>>
>>
>> --
>> Jeff Sq

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Jeff Squyres (jsquyres)]

Ok, weird.  Try running the process again (untar, configure, make) but use 
"make -d" and capture the entire output so that you can see what file(s) 
is(are) triggering Automake to invoke aclocal during the build (it will be a 
*LOT* of output).


> On Sep 1, 2016, at 1:20 PM, Sean Ahern  wrote:
> 
> Yep, that's it.
> -Sean
> 
> --
> Sean Ahern
> Computational Engineering International
> 919-363-0883
> 
> 
> On Thu, Sep 1, 2016 at 1:04 PM, Jeff Squyres (jsquyres)
>  wrote:
>> That's odd -- I've never seen this kind of problem happen on a 
>> locally-mounted filesystem.
>> 
>> Just to make sure: you're *not* running autogen.pl, right?  You're just 
>> basically doing this:
>> 
>> -
>> $ tar xf openmpi-2.0.0.tar.bz2
>> $ cd openmpi-2.0.0
>> $ ./configure ...
>> $ make ...
>> -
>> 
>> Right?
>> 
>> 
>>> On Sep 1, 2016, at 12:51 PM, Sean Ahern  wrote:
>>> 
>>> Greetings, Jeff.
>>> 
>>> Sure, I could see that. But I'm trying to run on a locally mounted 
>>> filesystem in this case. I may need to run make in debug mode and see what 
>>> it thinks is out of date. See if you guys can help me track down the 
>>> dependency problem.
>>> 
>>> -Sean
>>> 
>>> --
>>> Sean Ahern
>>> Computational Engineering International
>>> 919-363-0883
>>> 
>>> On Thu, Sep 1, 2016 at 11:56 AM, Jeff Squyres (jsquyres) 
>>>  wrote:
>>> Greetings Sean.
>>> 
>>> Yes, you are correct - when you build from the tarball, you should not need 
>>> the GNU autotools.
>>> 
>>> When tarball builds fail like this, it *usually* means that you are 
>>> building in a network filesystem, and the time is not well synchronized 
>>> between the machine on which you are building and the network filesystem 
>>> server.  Specifically: GNU Autotools-based builds are heavily dependent 
>>> upon filesystem timestamps.  If the sync is off between a network 
>>> filesystem client and server, all kinds of things go wrong (to include 
>>> thinking that it needs to run the autotools as part of the build).
>>> 
>>> 
>>> 
 On Sep 1, 2016, at 11:47 AM, Sean Ahern  wrote:
 
 I'm trying to compile OpenMPI 2.0.0 on a CentOS 6.7 system and am running 
 into what appears to be a very basic problem. I'm hoping someone here can 
 give me a pointer. (I'll have more involved questions later.) I've looked 
 through the FAQ for an answer and didn't see anything related. And I don't 
 see any messages in the archives from the last several years about this.
 
 I'm using the tarball 2.0.0 release, which presumably shouldn't require 
 the GNU autotools. But, after running "configure", the subsequent "make" 
 fails, trying to run aclocal-1.15.
 
 Here's running configure:
 
 % ./configure --prefix=blah/blah/openmpi-2.0.0 --disable-java 
 --disable-mpi-fortran
 
 == Configuring Open MPI
 
 
 *** Startup tests
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... x86_64-unknown-linux-gnu
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables...
 checking whether we are cross compiling... no
 … lots of output …
 config.status: creating ompi/mpiext/cuda/c/mpiext_cuda_c.h
 config.status: ompi/mpiext/cuda/c/mpiext_cuda_c.h is unchanged
 config.status: executing depfiles commands
 config.status: executing 
 opal/mca/event/libevent2022/libevent/include/event2/event-config.h commands
 config.status: executing libtool commands
 
 Seems fine. (If someone wants the full "configure" output, I'll send it.)
 But when I run "make", I immediately get this:
 
 % make all
 CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh 
 /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing 
 aclocal-1.15 -I config
 /home/sean/work/thirdparty/trunk/OpenMPI/openmpi-2.0.0/config/missing: 
 line 81: aclocal-1.15: command not found
 WARNING: 'aclocal-1.15' is missing on your system.
 You should only need it if you modified 'acinclude.m4' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'aclocal' program is part of the GNU Automake package:
 
 It also requires GNU Autoconf, GNU m4 and Perl in order to run:
 
 
 
 make: *** [aclocal.m4] Error 127
 
 I haven't modified any m4 files. Indeed, I haven't modified anything. I 
 simply ran "configure" and then "make". What am I doing wrong? I feel like 
 there's something v

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Sean Ahern]

Okay, I think I figured it out. The short answer is that version control
systems can mess up
​ ​
relative
file system timestamps.

While I was basically doing:

tar xzf openmpi-2.0.0.tar.gz
cd openmpi-2.0.0
./configure …
make


In actuality, I stored off the source in our "third party" repo before I
built it.

svn add openmpi-2.0.0

svn commit


When I grabbed that source back on the machine I wanted to build on, the
relative timestamps weren't the same as what I would have gotten with a
simple untar.


machine 1:
tar xvf openmpi-2.0.0.tar.gz
machine 1:
svn add openmpi-2.0.0

machine 1:
​ ​
svn commit

machine 2:
svn update openmpi-2.0.0
machine 2:
cd openmpi-2.0.0
machine 2:
./configure …
machine 2:
make


Thus, I got make dependencies like this:

  Finished prerequisites of target file `aclocal.m4'.
  Prerequisite `config/c_get_alignment.m4' is older than target
`aclocal.m4'.
  Prerequisite `config/c_weak_symbols.m4' is older than target
`aclocal.m4'.
  Prerequisite `config/libtool.m4' is older than target `aclocal.m4'.

Which is why it tried to rebuild portions of the autoconf configuration.

I think I can get things going again.

Sorry for the noise completely unrelated to OpenMPI!


-Sean

--
Sean Ahern
Computational Engineering International
919-363-0883

On Thu, Sep 1, 2016 at 1:24 PM, Jeff Squyres (jsquyres) 
wrote:

> Ok, weird.  Try running the process again (untar, configure, make) but use
> "make -d" and capture the entire output so that you can see what file(s)
> is(are) triggering Automake to invoke aclocal during the build (it will be
> a *LOT* of output).
>
>
> > On Sep 1, 2016, at 1:20 PM, Sean Ahern  wrote:
> >
> > Yep, that's it.
> > -Sean
> >
> > --
> > Sean Ahern
> > Computational Engineering International
> > 919-363-0883
> >
> >
> > On Thu, Sep 1, 2016 at 1:04 PM, Jeff Squyres (jsquyres)
> >  wrote:
> >> That's odd -- I've never seen this kind of problem happen on a
> locally-mounted filesystem.
> >>
> >> Just to make sure: you're *not* running autogen.pl, right?  You're
> just basically doing this:
> >>
> >> -
> >> $ tar xf openmpi-2.0.0.tar.bz2
> >> $ cd openmpi-2.0.0
> >> $ ./configure ...
> >> $ make ...
> >> -
> >>
> >> Right?
> >>
> >>
> >>> On Sep 1, 2016, at 12:51 PM, Sean Ahern  wrote:
> >>>
> >>> Greetings, Jeff.
> >>>
> >>> Sure, I could see that. But I'm trying to run on a locally mounted
> filesystem in this case. I may need to run make in debug mode and see what
> it thinks is out of date. See if you guys can help me track down the
> dependency problem.
> >>>
> >>> -Sean
> >>>
> >>> --
> >>> Sean Ahern
> >>> Computational Engineering International
> >>> 919-363-0883
> >>>
> >>> On Thu, Sep 1, 2016 at 11:56 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
> >>> Greetings Sean.
> >>>
> >>> Yes, you are correct - when you build from the tarball, you should not
> need the GNU autotools.
> >>>
> >>> When tarball builds fail like this, it *usually* means that you are
> building in a network filesystem, and the time is not well synchronized
> between the machine on which you are building and the network filesystem
> server.  Specifically: GNU Autotools-based builds are heavily dependent
> upon filesystem timestamps.  If the sync is off between a network
> filesystem client and server, all kinds of things go wrong (to include
> thinking that it needs to run the autotools as part of the build).
> >>>
> >>>
> >>>
>  On Sep 1, 2016, at 11:47 AM, Sean Ahern  wrote:
> 
>  I'm trying to compile OpenMPI 2.0.0 on a CentOS 6.7 system and am
> running into what appears to be a very basic problem. I'm hoping someone
> here can give me a pointer. (I'll have more involved questions later.) I've
> looked through the FAQ for an answer and didn't see anything related. And I
> don't see any messages in the archives from the last several years about
> this.
> 
>  I'm using the tarball 2.0.0 release, which presumably shouldn't
> require the GNU autotools. But, after running "configure", the subsequent
> "make" fails, trying to run aclocal-1.15.
> 
>  Here's running configure:
> 
>  % ./configure --prefix=blah/blah/openmpi-2.0.0 --disable-java
> --disable-mpi-fortran
>  
> 
>  == Configuring Open MPI
>  
> 
> 
>  *** Startup tests
>  checking build system type... x86_64-unknown-linux-gnu
>  checking host system type... x86_64-unknown-linux-gnu
>  checking target system type... x86_64-unknown-linux-gnu
>  checking for gcc... gcc
>  checking whether the C compiler works... yes
>  checking for C compiler default output file name... a.out
>  checking for suffix of executables...
>  checking whether we are cross compiling... no
>  … lots of output …
>  config.status: creating ompi/mpiext/cuda/c/mpiext_cuda_c.h
>  config.s

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Jeff Squyres (jsquyres)]

On Sep 1, 2016, at 2:05 PM, Sean Ahern  wrote:
> 
> In actuality, I stored off the source in our "third party" repo before I 
> built it.
> 
> svn add openmpi-2.0.0
> svn commit
> 
> When I grabbed that source back on the machine I wanted to build on, the 
> relative timestamps weren't the same as what I would have gotten with a 
> simple untar.

Ah yes, this will definitely be the cause.

The tarball is very carefully constructed to untar the files in a very specific 
order (i.e., the files are inserted in the tarball in the reverse order of 
timestamps which Automake needs), but when you put the tarball contents into a 
VCS, that ordering is not preserved.  Things go downhill from there.

FWIW, we usually store the tarballs themselves in VCSs if we want to preserve 
specific third-party tarballs.  It's a little gross (i.e., storing a big binary 
tarball in a VCS), but it works.  Depends on your tolerance level for "ick" in 
a VCS.  :-)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] Can't compile OpenMPI 2.0.0 on a CentOS 6 system

[Sean Ahern]

On Thu, Sep 1, 2016 at 3:14 PM, Jeff Squyres (jsquyres) 
wrote:

>
> FWIW, we usually store the tarballs themselves in VCSs if we want to
> preserve specific third-party tarballs.  It's a little gross (i.e., storing
> a big binary tarball in a VCS), but it works.  Depends on your tolerance
> level for "ick" in a VCS.  :-)
>
​
Not a bad idea! I may end up implementing precisely this for our work.

-Sean

--
Sean Ahern
Computational Engineering International
919-363-0883
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

[OMPI users] New to (Open)MPI

[Lachlan Musicman]

Hola,

I'm new to MPI and OpenMPI. Relatively new to HPC as well.

I've just installed a SLURM cluster and added OpenMPI for the users to take
advantage of.

I'm just discovering that I have missed a vital part - the networking.

I'm looking over the networking options and from what I can tell we only
have (at the moment) Fibre Channel over Ethernet (FCoE).

Is this a network technology that's supported by OpenMPI?

(system is running Centos 7, on Cisco M Series hardware)

Please excuse me if I have terms wrong or am missing knowledge. Am new to
this.

cheers
Lachlan


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] New to (Open)MPI

[Gilles Gouaillardet]

Hi,


FCoE is for storage, Ethernet is for the network.

I assume you can ssh into your nodes, which means you have a TCP/IP, and 
it is up and running.


i do not know the details of Cisco hardware, but you might be able to 
use usnic (native btl or via libfabric) instead of the plain TCP/IP network.



at first, you can build Open MPI, and run a job on two nodes with one 
task per node.


in your script, you can

mpirun --mca btl_base_verbose 100 --mca pml_base_verbose 100 ...

this will tell you which network is used.


Cheers,


Gilles

On 9/2/2016 11:06 AM, Lachlan Musicman wrote:

Hola,

I'm new to MPI and OpenMPI. Relatively new to HPC as well.

I've just installed a SLURM cluster and added OpenMPI for the users to 
take advantage of.


I'm just discovering that I have missed a vital part - the networking.

I'm looking over the networking options and from what I can tell we 
only have (at the moment) Fibre Channel over Ethernet (FCoE).


Is this a network technology that's supported by OpenMPI?

(system is running Centos 7, on Cisco M Series hardware)

Please excuse me if I have terms wrong or am missing knowledge. Am new 
to this.


cheers
Lachlan


--
The most dangerous phrase in the language is, "We've always done it 
this way."


- Grace Hopper


___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users


___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] New to (Open)MPI

[John Hearns via users]

Hello Lachlan.  I think Jeff Squyres will be along in a short while! HE is
of course the expert on Cisco.

In the meantime a quick Google turns up:
http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/usnic/c/deployment/2_0_X/b_Cisco_usNIC_Deployment_Guide_For_Standalone_C-SeriesServers.html

On 2 September 2016 at 06:54, Gilles Gouaillardet  wrote:

> Hi,
>
>
> FCoE is for storage, Ethernet is for the network.
>
> I assume you can ssh into your nodes, which means you have a TCP/IP, and
> it is up and running.
>
> i do not know the details of Cisco hardware, but you might be able to use
> usnic (native btl or via libfabric) instead of the plain TCP/IP network.
>
>
> at first, you can build Open MPI, and run a job on two nodes with one task
> per node.
>
> in your script, you can
>
> mpirun --mca btl_base_verbose 100 --mca pml_base_verbose 100 ...
>
> this will tell you which network is used.
>
>
> Cheers,
>
>
> Gilles
> On 9/2/2016 11:06 AM, Lachlan Musicman wrote:
>
> Hola,
>
> I'm new to MPI and OpenMPI. Relatively new to HPC as well.
>
> I've just installed a SLURM cluster and added OpenMPI for the users to
> take advantage of.
>
> I'm just discovering that I have missed a vital part - the networking.
>
> I'm looking over the networking options and from what I can tell we only
> have (at the moment) Fibre Channel over Ethernet (FCoE).
>
> Is this a network technology that's supported by OpenMPI?
>
> (system is running Centos 7, on Cisco M Series hardware)
>
> Please excuse me if I have terms wrong or am missing knowledge. Am new to
> this.
>
> cheers
> Lachlan
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
>
> ___
> users mailing 
> listus...@lists.open-mpi.orghttps://rfd.newmexicoconsortium.org/mailman/listinfo/users
>
>
>
> ___
> users mailing list
> users@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/users
>
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users