The attachment adds the necessary (cached) check for aio.h before
enabling fbtl:posix.
-Paul
On 2/17/2012 12:55 AM, Paul Hargrove wrote:
OpenBSD lacks an aio.h header.
configure knows this:
$ grep aio.h configure.log
checking aio.h usability... no
checking aio.h presence... no
Please note that "==" is NOT a portable binary operator for the "test"
utility.
It is supported only by the bash built-in version of "test".
The correct operator is a simple "=".
The following appear in the svn trunk
./orte/config/orte_check_alps.m4: AS_IF([test
"$orte_check_
If the processes are bound for L2 sharing (i.e. using neighboring cores pu:0
and pu:1) I get the *worst* latency results:
$ mpiexec -np 1 hwloc-bind pu:0 ./NPmpi -S -u 4 -n 10 : -np 1 hwloc-bind
pu:1 ./NPmpi -S -u 4 -n 10
Using synchronous sends
Using synchronous sends
0: n023
1: n023
No
Fixed -- thanks!
On Feb 20, 2012, at 4:11 AM, Paul H. Hargrove wrote:
> Please note that "==" is NOT a portable binary operator for the "test"
> utility.
> It is supported only by the bash built-in version of "test".
> The correct operator is a simple "=".
>
> The following appear in the svn tr
Applied -- thanks!
On Feb 20, 2012, at 12:31 AM, Paul H. Hargrove wrote:
> The attachment adds the necessary (cached) check for aio.h before enabling
> fbtl:posix.
> -Paul
>
> On 2/17/2012 12:55 AM, Paul Hargrove wrote:
>> OpenBSD lacks an aio.h header.
>> configure knows this:
>> $ grep aio.h
VT guys --
Can you have a look at this? I don't know if needs to be
protected or not, but it looks like it's needed.
Begin forwarded message:
> From: Aleksej Saushev
> Subject: [OMPI users] WEXITSTATUS: OpenMPI 1.5.5 RC1 doesn't build on NetBSD
> (and perhaps other BSDs)
> Date: February 18
Hi Paul -
Thanks for noticing this. I guess we don't have many Altix developers. I
think I've fixed it on the trunk with r25968, plus r25967 to make sure the
Altix component gets selected over the Linux component on Altix systems.
I don't have an Altix to test on; can you give it a go and let me
That was on my list of defects back in December.
This change is ALREADY present in the v1.5 branch in svn.
-Paul
On 2/20/2012 8:48 AM, Jeffrey Squyres wrote:
VT guys --
Can you have a look at this? I don't know if needs to be
protected or not, but it looks like it's needed.
Begin forwarded
Brian,
Thanks for looking into this.
I'll plan to take a look at the trunk tarball tonight and report back.
-Paul
On 2/20/2012 8:49 AM, Barrett, Brian W wrote:
Hi Paul -
Thanks for noticing this. I guess we don't have many Altix developers. I
think I've fixed it on the trunk with r25968, pl
I am afraid that with the $with_platform instance fixed, configure on
Solaris 10 gets far enough to find another problem.
I'll provide a patch once I've tracked this down. Sigh.
FYI:
One can root out bashisms by using the "dash" shell on a Debian or
Ubuntu system:
$ env CONFIG_SHELL=dash dash
grep == configure | grep test
only shows one more. I found it in config/ompi_load_platform.m4 and fixed it
on the trunk.
On Feb 20, 2012, at 3:38 PM, Paul H. Hargrove wrote:
> I am afraid that with the $with_platform instance fixed, configure on Solaris
> 10 gets far enough to find another p
Jeff,
The one in config/ompi_load_platform.m4 was on my original hit-list.
Getting PAST that one shows a new problem that appears NOT to be a "==".
The autoconf manual warns about use of "-a" and "-o" together with
variables that may expand to the empty string, and I suspect that is the
new pro
Ah, ok.
On Feb 20, 2012, at 3:45 PM, Paul H. Hargrove wrote:
> Jeff,
>
> The one in config/ompi_load_platform.m4 was on my original hit-list.
> Getting PAST that one shows a new problem that appears NOT to be a "==".
> The autoconf manual warns about use of "-a" and "-o" together with variables
Not what I had expected to find, but a pretty simple fix (missing line
continuation):
Index: orte/mca/ess/alps/configure.m4
===
--- orte/mca/ess/alps/configure.m4 (revision 25970)
+++ orte/mca/ess/alps/configure.m4 (workin
Argh!!
I am now trying to track down "expr: Paren problem" on Solaris.
The dash shell on Linux doesn't reproduce this one, unfortunately.
-Paul
On 2/20/2012 1:12 PM, Paul H. Hargrove wrote:
I'll report back ASAP on my slowlaris10 results.
--
Paul H. Hargrove phhargr..
Committed -- thanks.
Confirmed that it's not in v1.5, too. Just for good measure.
On Feb 20, 2012, at 4:12 PM, Paul H. Hargrove wrote:
> Not what I had expected to find, but a pretty simple fix (missing line
> continuation):
>
> Index: orte/mca/ess/alps/configure.m4
> ===
Yo Brian --
Do we need to bring this to v1.5, too?
On Feb 20, 2012, at 11:49 AM, Barrett, Brian W wrote:
> Hi Paul -
>
> Thanks for noticing this. I guess we don't have many Altix developers. I
> think I've fixed it on the trunk with r25968, plus r25967 to make sure the
> Altix component get
I'm afraid this commit breaks the ability to build from a tarball. I created a
tarball from the trunk and then did a configure followed by "make clean". The
make command failed to execute because it could not "make clean" in the
mca/fbtl/posix directory as there is no Makefile in it.
I checked
Short version:
The "expr: Paren problem" comes from having /usr/ucb/bin ahead of
/usr/bin in one's $PATH.
So, I needed to fix my $PATH.
Long version:
This error is coming from configure's own argument parsing logic when
the ROMIO sub-configure is invoked.
The issue appears to be that the expr
I'll dig…
On Feb 20, 2012, at 5:36 PM, Ralph Castain wrote:
> I'm afraid this commit breaks the ability to build from a tarball. I created
> a tarball from the trunk and then did a configure followed by "make clean".
> The make command failed to execute because it could not "make clean" in the
That's because Jeff forgot to copy the line:
AC_CONFIG_FILES([ompi/mca/fbtl/posix/Makefile])
>From whatever configure.m4 script he used as the base for his new macro :).
Brian
On 2/20/12 3:36 PM, "Ralph Castain" wrote:
>I'm afraid this commit breaks the ability to build from a tarball. I
>c
For those keeping score at home, that should have said "/usr/ucb"
instead of "/usr/ucb/bin".
I make mistakes too (as Ralph's observation of breakage w/ r25966 shows
quite clearly).
-Paul
On 2/20/2012 2:37 PM, Paul H. Hargrove wrote:
Short version:
The "expr: Paren problem" comes from having /
s/Jeff/Paul/
Jeff's only fault was trusting me too much.
-Paul
On 2/20/2012 2:41 PM, Barrett, Brian W wrote:
That's because Jeff forgot to copy the line:
AC_CONFIG_FILES([ompi/mca/fbtl/posix/Makefile])
> From whatever configure.m4 script he used as the base for his new macro:).
Brian
--
Added… thanks.
On Feb 20, 2012, at 5:41 PM, Barrett, Brian W wrote:
> That's because Jeff forgot to copy the line:
>
> AC_CONFIG_FILES([ompi/mca/fbtl/posix/Makefile])
>
>> From whatever configure.m4 script he used as the base for his new macro :).
>
> Brian
>
> On 2/20/12 3:36 PM, "Ralph Ca
FWIW, I think we're still going to have another problem with "make dist" --
some of the Java header files are generated. I'm not sure we have that right
in the Makefile.am.
I committed this fbtl fix; I'll try "make dist" now, but I have to run for a
while. I may or may not get this done by th
Ralph,
Are you sure this is a flex-generated file?
I am looking at opal/util/show_help_lex.l in the svn trunk and it
certainly looks human-generated to me.
Please clue me in if I am missing something.
The warning is from flex when processing the .l file, NOT from the
compilation of the flex-g
It looks okay, Jeff - I ran make diet and all the headers are in the resulting
tarball.
On Feb 20, 2012, at 4:03 PM, Jeffrey Squyres wrote:
> FWIW, I think we're still going to have another problem with "make dist" --
> some of the Java header files are generated. I'm not sure we have that ri
My bad - didn't look closely enough. I'll take a look at it and see if there is
anything we can do.
On Feb 20, 2012, at 4:12 PM, Paul H. Hargrove wrote:
> Ralph,
>
> Are you sure this is a flex-generated file?
> I am looking at opal/util/show_help_lex.l in the svn trunk and it certainly
> look
Ralph,
The change below removes the warning, but very slightly changes the
syntax that is parsed.
In the original, anything following the "[tag]" was considered trailing
context.
However that made inputs like "[tag]foo]" ambiguous to the parser (hence
the warning).
With the change below, both
Thanks! I'll have to move to another machine to test, though - my Mac Lion is
running flex 2.5.35, and I no longer see those warnings. Interesting as I was
under the impression that flex is no longer supported….
On Feb 20, 2012, at 4:36 PM, Paul H. Hargrove wrote:
> Ralph,
>
> The change belo
just out of curiosity, what platform did not have support for the aio
operations?
Also, the proper solution will be to not compile the section using the
aio functions, but still compile the rest of the module. I will try to
implement that properly ASAP. The POSIX is the most basic module that
shal
The original problem of a missing aio.h was seen on OpenBSD-5.0 (which
was released Nov 1, 2011)
See http://www.open-mpi.org/community/lists/devel/2012/02/10470.php
-Paul
On 2/20/2012 4:03 PM, Edgar Gabriel wrote:
just out of curiosity, what platform did not have support for the aio
operation
On 2/20/2012 3:36 PM, Paul H. Hargrove wrote:
NOTE: I've not yet actually tested the resulting show_help utility
[but soon].
An "instrumented" version of test/opal_sos.c is getting the same string
back from opal_show_help_string() both with and without my patch. So, I
believe it to be cor
Both the v1.5 branch and trunk are getting lots of warnings from Clang
like the following:
CC ad_coll_exch_new.lo
../../../../../../../../ompi/mca/io/romio/romio/adio/common/ad_coll_exch_new.c:51:28:
warning: length modifier
'L' results in undefined behavior or no effect with 'd' conversi
We've been forwarding all of these kinds of fixes upstream.
On Feb 20, 2012, at 7:23 PM, Paul H. Hargrove wrote:
> Both the v1.5 branch and trunk are getting lots of warnings from Clang like
> the following:
>> CC ad_coll_exch_new.lo
>> ../../../../../../../../ompi/mca/io/romio/romio/adio/
I committed a minor fix which seems to fix the issue (i.e., if you didn't
already have the .h files generated).
On Feb 20, 2012, at 6:24 PM, Ralph Castain wrote:
> It looks okay, Jeff - I ran make diet and all the headers are in the
> resulting tarball.
>
>
> On Feb 20, 2012, at 4:03 PM, Jeff
36 matches
Mail list logo
