On 8/16/07, George Bosilca wrote:
> Well, finally someone discovered it :) I know about this problem for
> quite a while now, it pop up during our own valgrind test of the
> collective module in Open MPI. However, it never create any problems
> in the applications, at least not as far as I know. T
On Fri, Aug 17, 2007 at 03:08:12PM +0200, Manuel Prinz wrote:
> Am Freitag, den 17.08.2007, 09:02 -0400 schrieb Jeff Squyres:
> > I don't think those options are safe on any architecture.
>
> I'll disable them in debian/rules then and document it.
>
> Dirk, are you fine with that?
Sure thing. We
I thought about both of those (/tmp/private and /tmp/public), but couldn't
think of a way to make them work.
1. If we do /tmp/private, we have to svn mv all the existing trees there which
will annoy the developers (but is not a deal-breaker) and make /tmp publicly
readable. But that makes the
Fixed. Sorry about the configure change mid-day, but it seemed like
the right thing to do.
Brian
On Aug 17, 2007, at 10:37 AM, Brian Barrett wrote:
Oh, crud. I forgot to fix that issue. Will fix asap.
Brian
On Aug 17, 2007, at 10:12 AM, George Bosilca wrote:
This patch break the trun
Oh, crud. I forgot to fix that issue. Will fix asap.
Brian
On Aug 17, 2007, at 10:12 AM, George Bosilca wrote:
This patch break the trunk. It looks like the LT_PACKAGE_VERSION
wasn't defined before the 2.x version. The autogen fails with the
following error:
*** Running GNU tools
[Running]
This patch break the trunk. It looks like the LT_PACKAGE_VERSION
wasn't defined before the 2.x version. The autogen fails with the
following error:
*** Running GNU tools
[Running] autom4te --language=m4sh ompi_get_version.m4sh -o
ompi_get_version.sh
[Running] aclocal
configure.ac:998: erro
ugh, sorry, I've been busy this week and didn't see a timeout, so a
response got delayed.
I really don't like this format. public doesn't have any meaning to
it (tmp suggests, well, it's temporary). I'd rather have /tmp/ and /
tmp/private or something like that. Or /tmp/ and /tmp/public/.
Am Freitag, den 17.08.2007, 09:02 -0400 schrieb Jeff Squyres:
> I don't think those options are safe on any architecture.
I'll disable them in debian/rules then and document it.
Dirk, are you fine with that?
Best regards
Manuel
On Aug 17, 2007, at 8:57 AM, Manuel Prinz wrote:
Jeff, do you know for which architectures it's (not) working? I
haven't
experienced problems so far, or at least didn't notice them.
I don't think those options are safe on any architecture. We're
working on the trunk to make them actually
Am Freitag, den 17.08.2007, 14:49 +0200 schrieb Adrian Knoth:
> On Fri, Aug 17, 2007 at 08:26:50AM -0400, Jeff Squyres wrote:
>
> > > Ok, --enable-progress-threads and --enable-mpi-threads cause the
> > > segfaults. If you compile without, everything works.
> >
> > > I'll now try if it's mpi-thre
On Fri, Aug 17, 2007 at 08:26:50AM -0400, Jeff Squyres wrote:
> > Ok, --enable-progress-threads and --enable-mpi-threads cause the
> > segfaults. If you compile without, everything works.
>
> > I'll now try if it's mpi-threads or the progress-threads, and also
> > check
> > the upcoming v1.2.4.
I am definitely interested to see what the RSL turns out to be; I
think it has many potential benefits. There are also some obvious
issues to be worked out (e.g., mpirun and friends).
As for whether this should go in v1.3, I don't know if it's possible
to say yet -- it will depend on when
On Aug 17, 2007, at 8:22 AM, Sven Stork wrote:
What's about this. Every component choose its own tag independent
from the
others. Before a component can use the tag it must register with
its full
name and the tag at a small (process intern) database. If 2
components try to
register the same
On Aug 17, 2007, at 8:10 AM, Adrian Knoth wrote:
Ok, --enable-progress-threads and --enable-mpi-threads cause the
segfaults. If you compile without, everything works.
I'll now try if it's mpi-threads or the progress-threads, and also
check
the upcoming v1.2.4.
The --enable-progress-thread
On Friday 17 August 2007 13:58, Jeff Squyres wrote:
> On Aug 16, 2007, at 1:13 PM, Tim Prins wrote:
>
> >> So you're both right. :-) But Tim's falling back on an older (and
> >> unfortunately bad) precedent. It would be nice to not extend that
> >> bad precedent, IMHO...
> >
> > I really don't
I didn't really put this in RFC format with a timeout, but no one
objected, so I have created:
http://svn.open-mpi.org/svn/ompi/public
Developers should feel free to use this tree for public temporary
branches. Specifically:
- use /tmp if your branch is intended to be private
- us
On Fri, Aug 17, 2007 at 09:25:05AM +0200, Adrian Knoth wrote:
> I've tried both: the tarball works fine, the Debian package
> segfaults. I suspect it's the threading support, so someone (Uwe?) could
> try to remove it from debian/rules.
Ok, --enable-progress-threads and --enable-mpi-threads cause
On Aug 16, 2007, at 1:13 PM, Tim Prins wrote:
So you're both right. :-) But Tim's falling back on an older (and
unfortunately bad) precedent. It would be nice to not extend that
bad precedent, IMHO...
I really don't care where the constants are defined, but they do
need to
be unique. I th
On Aug 16, 2007, at 8:11 PM, Uwe Hermann wrote:
With the libc0.1 fix (and another small patch for Debian which I'll
send soon)
both the kfreebsd-i386 and kfreebsd-amd64 packages build fine.
However, on my systems, both i386 and amd64 still segfault. I'm using
the openmpi Debian packages, vers
On Fri, Aug 17, 2007 at 02:11:02AM +0200, Uwe Hermann wrote:
> > | The 1.2.3 release also works fine:
> I think Adrian used a tarball, not the Debian package?
> I'll try a local, manual install too, maybe the bug is Debian-related only?
I've tried both: the tarball works fine, the Debian package
20 matches
Mail list logo
