The only one of those we link against is libpmi. Why they chose to link libpmi
against libslurm and libhwloc is beyond belief - not only are those libs
irrelevant to pmi, but they also contain fully GPL code.
Afraid you'll have to take it up with them. This isn't something we can solve.
NOTE: f
Hmmm... --enable-static works just fine (at least, for the 1.8.2rc) on CentOS,
so this may be a Debian thing. We have some protection in there for getpwuid on
the Cray, where static builds take similar exception to it, but that requires
you configure with --disable-getpwuid. I was unaware of p
Dear developers and subscribers,
I'm not aware of information how open-mpi static build is being
validated. Is there any documentation about it?
For now I tested the static build on Debian Jessie (testing) amd64
with openmpi-1.6.5 and openmpi-1.8.1.
There are few issues with it.
- openmpi doesn
okay, seems found the reason:
slurm-devel-14.03.4-2.el6.x86_64 comes with this:
$grep hwloc /usr/lib64/*la
/usr/lib64/libpmi.la:dependency_libs=' /usr/lib64/libslurm.la -L/usr/lib64
-ldl -lhwloc -lpthread'
/usr/lib64/libslurmdb.la:dependency_libs=' -L/usr/lib64 -ldl -lhwloc
-lpthread'
/usr/li
ohh... sorry about that.
will be more careful next time.
On Sat, Jul 12, 2014 at 8:43 PM, Ralph Castain wrote:
> Congrats - your Makefile.am change broke it :-)
>
> I reverted it so the repo can build again
>
> On Jul 12, 2014, at 10:23 AM, Mike Dubman
> wrote:
>
> From repo
> On Jul 12, 2014
Congrats - your Makefile.am change broke it :-)
I reverted it so the repo can build again
On Jul 12, 2014, at 10:23 AM, Mike Dubman wrote:
> From repo
>
> On Jul 12, 2014 7:59 PM, "Ralph Castain" wrote:
> Just checked out the tarball and it builds fine for me - did you build this
> from the
>From repo
On Jul 12, 2014 7:59 PM, "Ralph Castain" wrote:
> Just checked out the tarball and it builds fine for me - did you build
> this from the tarball, or from the repo?
>
>
> On Jul 12, 2014, at 9:29 AM, Mike Dubman wrote:
>
> make[8]: Entering directory
> `/hpc/newhome/hpcuser/workspace/h
Just checked out the tarball and it builds fine for me - did you build this
from the tarball, or from the repo?
On Jul 12, 2014, at 9:29 AM, Mike Dubman wrote:
> make[8]: Entering directory
> `/hpc/newhome/hpcuser/workspace/hpc-internal-tools.git/build/dist-ompi-mellanox-v1.8-1.8/master/ompi/
Okay, let's clarify a couple of things:
1. this wasn't "necessary" in the sense that OMPI won't build without the
change. It was "desirable" in terms of eliminating some long-standing warnings
coming from those areas due to changes in automake in anticipation of a
compatibility break when autom
make[8]: Entering directory
`/hpc/newhome/hpcuser/workspace/hpc-internal-tools.git/build/dist-ompi-mellanox-v1.8-1.8/master/ompi/contrib/vt/vt/extlib/otf/tools/otfinfo'
make[8]: Leaving directory
`/hpc/newhome/hpcuser/workspace/hpc-internal-tools.git/build/dist-ompi-mellanox-v1.8-1.8/master/ompi/c
Yep
On Jul 12, 2014 7:23 PM, "Jeff Squyres (jsquyres)"
wrote:
> Mike --
>
> Was this actually necessary in the libevent directory too? What version
> of "new" automake are you referring to -- 1.14? (I'm not sure I've tried
> 1.14.x... my cluster version is still at 1.13.x)
>
>
>
> On Jul 12
Mike --
Was this actually necessary in the libevent directory too? What version of
"new" automake are you referring to -- 1.14? (I'm not sure I've tried
1.14.x... my cluster version is still at 1.13.x)
On Jul 12, 2014, at 8:38 AM, svn-commit-mai...@open-mpi.org wrote:
> Author: miked (
Hello,
Just fyi: have forwarded the logs below to the VT mailing list
at Vampir-Support
Ticket number: 2014071241000219
-- Sid
Univ. of Houston
On 12 July 2014 17:51, Jeff Squyres (jsquyres) wrote:
> Yes, but they're a 3rd party -- they rarely pay attention to OMPI stuff
> unless we ping the
The backups were sketchy, but I found an old password file that I think should
have all the correct MTT submission passwords.
Please let me know if you have problems submitting MTT results.
Sorry for the hassle.
On Jul 12, 2014, at 7:54 AM, Jeff Squyres wrote:
> $#%@#%
>
> Somehow the MTT s
Yes, but they're a 3rd party -- they rarely pay attention to OMPI stuff unless
we ping them specifically (CC'ed).
They keep their tree in tight sync with the VT copy in the OMPI SVN -- they
should be consulted with these kinds of changes.
Andreas / Matthias -- any problems with this change?
Nope
Are they on list?
On Jul 12, 2014 6:36 PM, "Jeff Squyres (jsquyres)"
wrote:
> Mike --
>
> Did you contact the VT folks before making this change?
>
>
>
> On Jul 12, 2014, at 8:38 AM, <
> svn-commit-mai...@open-mpi.org> wrote:
>
> > Author: miked (Mike Dubman)
> > Date: 2014-07-12 08:38:15 E
Mike --
Did you contact the VT folks before making this change?
On Jul 12, 2014, at 8:38 AM,
wrote:
> Author: miked (Mike Dubman)
> Date: 2014-07-12 08:38:15 EDT (Sat, 12 Jul 2014)
> New Revision: 32225
> URL: https://svn.open-mpi.org/trac/ompi/changeset/32225
>
> Log:
> BUILD: support new
you are right about setting 'dist %{nil}' will workaround about the src.rpm
filename issue.
but we are using contrib/dist/linux/buildrpm.sh script and not calling
rpmbuild directly.
I don`t mind having %{?dist} in the spec file, as long as this change is
backwards compatible:
You can change buil
$#%@#%
Somehow the MTT submission password file just got truncated. I have asked IU
to restore a copy from their backups, but I don't know who's around over the
weekend.
As a result, MTT submissions may get rejected until the password file is
restored.
Sorry folks...
--
Jeff Squyres
jsquy.
This is a bad idea to remove the %{?dist} IMHO.
To generate a generic src.rpm, you should use the following command:
rpmbuild -ts tarball --define 'dist %{nil}'
or
rpmbuild -bs openmpi.spec --define 'dist %{nil}'
This can be put in the main Maikefile:
srpm: tarball_bz2
rpmbuild -ts openmpi
20 matches
Mail list logo
