Hey folks
Something in the last day or so appears to have broken the trunk's ability to
run --with-devel-headers. It looks like the headers are being installed
correctly, but mpicc fails to compile a program that uses them - the include
passes, but the linker fails:
Undefined symbols for archi
Actually, it already is set correctly - the help message was out of date, so I
corrected that.
On Jul 24, 2014, at 10:58 AM, Marco Atzeri wrote:
> On 24/07/2014 15:52, Ralph Castain wrote:
>> Oshmem should be enabled by default now
>
> Ok,
> so please reverse the configure switch
>
> --enabl
On Jul 24, 2014, at 2:00 PM, Mike Dubman wrote:
> OSHMEM memheap implementation relies on the "_end" symbol provided by linux
> linker. The _end symbol indicates the beginning of the program dynamic
> allocation area.
> This is needed to allow programmatic access to the process global/static
OSHMEM memheap implementation relies on the "_end" symbol provided by linux
linker. The _end symbol indicates the beginning of the program dynamic
allocation area.
This is needed to allow programmatic access to the process global/static
variables.
On Thu, Jul 24, 2014 at 9:22 PM, Marco Atzeri
On Jul 24, 2014, at 2:20 PM, Bert Wesarg wrote:
>> Now there is still a problem: Matthias Jurenz is on vacation until
>> August 5th. and I'm completely unfamiliar with the procedure how the VT
>> code is updated in the ompi trunk. For what I see it should go like this:
>>
>> 1. Commit into vendo
WHAT: Bump up the minimum sm pool size to 128K from 64K.
WHY: When running OSU benchmark on 2 nodes and utilizing a larger
btl_smcuda_max_send_size, we can run into the case where the free list cannot
grow. This is not a common case, but it is something that folks sometimes
experiment with.
Hi,
I had the impression that the scope of using autotools is
to check for features not platforms.
*** OSHMEM Configuration options
checking if want oshmem... yes
configure: WARNING: OpenSHMEM support was requested, but currently
configure: WARNING: only supports Linux.
configure: error: Cannot
On 07/24/2014 07:01 PM, Bert Wesarg wrote:
Now there is still a problem: Matthias Jurenz is on vacation until
August 5th. and I'm completely unfamiliar with the procedure how the VT
code is updated in the ompi trunk. For what I see it should go like this:
1. Commit into vendor/vampirtrace/curren
On 24/07/2014 15:52, Ralph Castain wrote:
Oshmem should be enabled by default now
Ok,
so please reverse the configure switch
--enable-oshmem Enable building the OpenSHMEM interface
(disabled by default)
I will test enabling it in the meantime.
Regards
Marco
Just for the record: The --disable-dependency-tracking triggers the
problem. Which rpmbuild probably passes to the configure call.
Bert
On 07/24/2014 07:01 PM, Bert Wesarg wrote:
On 07/24/2014 03:59 PM, Jeff Squyres (jsquyres) wrote:
Another data point:
I just bootstrapped with Automake 1.14
On 07/24/2014 03:59 PM, Jeff Squyres (jsquyres) wrote:
Another data point:
I just bootstrapped with Automake 1.14.1, and got the same result (i.e., ls -l before configure,
the "hooks" directory is NOT there, run configure, ls -l and the "hooks"
directory IS there).
I'm guessing something chan
My guess is that no one is testing the bfo PML. However, I would have expected
it to still work with Open MPI 1.6.5. From your description, it works for
smaller messages but fails with larger ones? So, if you just send smaller
messages and pull the cable, things work correctly?
One idea is t
Another data point:
I just bootstrapped with Automake 1.14.1, and got the same result (i.e., ls -l
before configure, the "hooks" directory is NOT there, run configure, ls -l and
the "hooks" directory IS there).
I'm guessing something changed elsewhere in the toolchain on RHEL7/SLES12(beta)
tha
Oshmem should be enabled by default now
On Jul 23, 2014, at 9:52 PM, Marco Atzeri wrote:
> On 24/07/2014 01:05, Ralph Castain wrote:
>> Usual place:
>>
>> http://www.open-mpi.org/software/ompi/v1.8/
>>
>> Please test and report problems by Wed July 30
>>
>> Thanks
>> Ralph
>>
>
> on cygwin
On Jul 24, 2014, at 8:55 AM, Bert Wesarg wrote:
> But the dep rules should already ensure this, as it creates the .deps
> directory at the end of configure. Though if this is not guaranteed to happen
> (maybe it depends on the used compiler) than we would need to ensure it in
> the makefile it
Mike --
If this is Autotools related, then it should be possible to replicate on RHEL
6.x machines.
What versions of all the autootools are you using?
Autoconf
Automake
Libtool
m4
On Jul 24, 2014, at 8:39 AM, Mike Dubman wrote:
> it seems autotools related:
> it tries to create link in "hoo
On 07/24/2014 02:52 PM, Peter Breitenlohner wrote:
On Thu, 24 Jul 2014, Mike Dubman wrote:
it seems autotools related:
it tries to create link in "hooks" subfolder which does not present.
This typically occurs when you try to create a file (symlink) in a
nonexistent directory. In such situat
On Thu, 24 Jul 2014, Mike Dubman wrote:
it seems autotools related:
it tries to create link in "hooks" subfolder which does not present.
This typically occurs when you try to create a file (symlink) in a
nonexistent directory. In such situations the make rules must ensure that
such directorie
it seems autotools related:
it tries to create link in "hooks" subfolder which does not present.
linux:/var/tmp/OFED_topdir/BUILD/openmpi-1.8.2rc2/ompi/contrib/vt/vt/tools/vtunify/mpi
# ls -al
total 248
drwxr-xr-x 1 hpcuser mtl 474 Jul 24 15:32 .
drwxr-xr-x 1 hpcuser mtl1058 Jul 24 15:16
Hello,
Is there anybody using/testing the bfo PML - especially with messages > eager
limit?
Tests using messages > eager limit with the bfo PML seem to deadlock in Open
MPI 1.6.5 as soon as one of two infiniband connections gets lost (tested by
disconnecting wire).
I did not have an opportunit
I just tried it myself -- "make distcheck" succeeds for both a nightly tarball
(openmpi-1.8.2rc2r32302) and in a git or svn checkout on RHEL 6.5.
I do not have easy access to RHEL 7 or SLES 12 beta.
Can someone analyze this and figure out what the difference is?
On Jul 24, 2014, at 6:21 AM, J
On Jul 24, 2014, at 2:55 AM, Bert Wesarg
mailto:bert.wes...@tu-dresden.de>> wrote:
may I suggest to increase the timeout next year. I think it is vacation time
around the world and a deadline from 1 week seems very short and may be easily
missed. I'm the only one from the three Dresden guys who
I am getting reports of similar failures from Cisco QA. They have clean/fresh
checkouts of the OMPI tree.
It does not seem to happen on RHEL 6.5, but does happen on RHEL 7 and SLES 12
(beta).
What's the difference?
On Jul 24, 2014, at 6:12 AM, Mike Dubman wrote:
> this is a command line we
this is a command line we use:
cd ./contrib/dist/linux
./contrib/dist/make_tarball -greekonly
rpmbuild --rebuild --define '_topdir /var/tmp//OFED_topdir' --define 'dist
%{nil}' --target x86_64 --define '_name openmpi' --define 'mpi_selector
/usr/bin/mpi-selector' --define 'use_mpi_selector 1' --d
On 07/24/2014 10:15 AM, Mike Dubman wrote:
the problem occurs when build is started from src.rpm (and probably from
tarball as well):
try make distcheck and use src tree from tarball.
I did now make distcheck from the rc2 tarball, and it all worked. I
don't know what the srpm does differently
the problem occurs when build is started from src.rpm (and probably from
tarball as well):
try make distcheck and use src tree from tarball.
On Thu, Jul 24, 2014 at 10:57 AM, Bert Wesarg
wrote:
> On 07/24/2014 09:32 AM, Mike Dubman wrote:
>
>> yes, sure - it fails on sles12, rhel 7, fedora 14-
On 07/24/2014 09:32 AM, Mike Dubman wrote:
yes, sure - it fails on sles12, rhel 7, fedora 14-20, debian 6.5-7.5,
ubuntu 12-14
It fails on "rpmbuild" from latest ompi-1.8.2rc2.src.rpm
it passes on rhel 6.x, sles 11.x, oel
Just tried the rc2 package, but I could not reproduce it on Ubuntu
12.0
yes, sure - it fails on sles12, rhel 7, fedora 14-20, debian 6.5-7.5,
ubuntu 12-14
It fails on "rpmbuild" from latest ompi-1.8.2rc2.src.rpm
it passes on rhel 6.x, sles 11.x, oel
make[6]: Entering directory
'/var/tmp/OFED_topdir/BUILD/openmpi-1.8.2rc2/ompi/contrib/vt/vt/tools/vtunify/mpi'
ln -s
/
Hi,
On 07/23/2014 04:52 PM, Jeff Squyres (jsquyres) wrote:
It is that time again -- it's time to clean house of SVN write access accounts.
SHORT VERSION
=
Edit the wiki to preserve your organization's SVN accounts by COB, Thursday,
July 31, 2014:
may I suggest to increase the ti
On 24/07/2014 01:05, Ralph Castain wrote:
Usual place:
http://www.open-mpi.org/software/ompi/v1.8/
Please test and report problems by Wed July 30
Thanks
Ralph
on cygwin 64bit, it builds and passes tests except known
https://svn.open-mpi.org/trac/ompi/ticket/4195#
Question: oshmem was supp
30 matches
Mail list logo
