Sorry for the somewhat off-topic question:
What tool(s) are you using to generate web pages for your wonderfully
organized FAQ?
-Paul
--
Paul H. Hargrove
Pronouns: he, him, his
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department
Lawrence Berkeley National Laboratory
I
=dWPv
-END PGP SIGNATURE-
___
hwloc-devel mailing list
hwloc-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research De
showing me the logical->physical layout of
screens on a multi-headed X server, right?
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
URE-
___
hwloc-devel mailing list
hwloc-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel:
On 2/28/2012 5:09 PM, Christopher Samuel wrote:
On 29/02/12 07:44, Jeffrey Squyres wrote:
> - BlueGene fixes
rc3 fixes the builds on our front end node, thanks!
And on a BG/L (not a typo) front-end too, where the same problem existed
in prior versions.
-Paul
--
Paul H. Hargr
.
+ * Copyright (c) 2011 Los Alamos National Security, LLC.
* All rights reserved.
* $COPYRIGHT$
*
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley
BlueGene fixes
- Fix processor affinity for some old/weird platforms
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
/
Given the amount of testing we've had, this rc might actually be pretty close.
Lots and lots of changes since rc1; I'm not even going to bother to list them
all.
Please test!
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department
inserting a cast, and I believe it should
apply cleanly to both v1.5 branch (for v1.6) and to the trunk.
-Paul
On 2/24/2012 5:46 PM, Paul H. Hargrove wrote:
Hmm, I was certain I knew what was wrong, but the tests still fail.
Nobody should hold their breath waiting for my patches, but I am still
, I think this is a 1.6 issue.
-Paul
On 2/24/2012 5:19 PM, Paul H. Hargrove wrote:
I see now why I get "check" failures from the opal atomics w/ XLC-9.0.
The inline asm is mildly incorrect and I am actually surprised gcc
didn't produce bad code.
Patch(es) will be sent ASAP as I think t
I see now why I get "check" failures from the opal atomics w/ XLC-9.0.
The inline asm is mildly incorrect and I am actually surprised gcc
didn't produce bad code.
Patch(es) will be sent ASAP as I think this should be fixed for 1.5.5.
-Paul
On 2/23/2012 8:24 PM, Paul H. Harg
-AROUND
to allow testing w/o waiting for the CMR to be processed.
-Paul
On 2/24/2012 1:14 PM, Paul H. Hargrove wrote:
Christopher,
Just wanted to note that when you build like this on the BG/P front
end, VT is detecting the BG/P environment and so trying to build for
the BG/P compute node
ilman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
-END PGP SIGNATURE-
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-
Sorry folks. That was intended just for Jeff's eyes, but my fingers
moved faster than my brain.
No offense was intended.
-Paul
On 2/23/2012 10:01 AM, Paul H. Hargrove wrote:
I think the VT folks get blamed often enough for build issues w/o
attributing one more problem to them.
On 2/23
I think the VT folks get blamed often enough for build issues w/o
attributing one more problem to them.
On 2/23/2012 9:47 AM, Jeffrey Squyres wrote:
Cool; thanks for setting this straight.
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC
.
On Feb 22, 2012, at 3:16 PM, Paul H. Hargrove wrote:
I think I have the beginning of a fix for this issue.
I had not even noticed earlier that the error in event.h is from the C++
compiler, when compiling file.cxx in the c++ bindings. That makes the
vendor-specific addition of "-li
r
US Geological Survey
650-329-5608
ba...@usgs.gov <mailto:ba...@usgs.gov>
On 22 Feb 2012, at 5:55 PM, Paul H. Hargrove wrote:
Folks at Oracle should decide, but I suspect "Solaris 10" should be
updated to "Solaris 10 and 11", or just "11".
-Paul
On 2/22/
er/usr/llvm-gcc-4.2/bin/i686-apple-darwin9-llvm-gcc-4.2
/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
/Developer/usr/llvm-gcc-4.2/bin/powerpc-apple-darwin9-llvm-gcc-4.2
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov <mailto:ba...@usgs.gov>
On 22 Feb 2012, at 5:55 PM, Paul H. Ha
latforms (e.g., Linux on PPC64)
- Microsoft Windows CCP (Microsoft Windows server 2003 and 2008);
see the README.WINDOWS file.
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley N
ORT is also defined.
So, maybe I am over thinking this.
-Paul
On 2/21/2012 11:10 PM, Paul H. Hargrove wrote:
More notes:
I've tested ompi-1.5.4 and it has the same problem. So, this is NOT a
regression.
Terry D. has observed that Ubuntu is NOT a supported platform for the
Solaris Studio compil
SUCCESSFUL.
So, one has 2 choices:
+ build w/ SS12.2 without VT
+ update to SS12.3 and have VT
I don't think there is sufficient reason to delay 1.5.5 for this.
-Paul
On 2/21/2012 4:39 PM, Paul H. Hargrove wrote:
A few things to note:
1) This is NOT a problem w/ the SS12.3 compilers on the sa
My build with the "2011_sp1.8.273" Intel compilers passes the same tests
as I detailed below for "2011_sp1.7.256".
I don't suspect any longer that the compiler is at fault, but am willing
to try additional/alternate tests to help confirm.
-Paul
On 2/21/2012 5:40 PM, Pa
ay right now (est.
45minutes to complete - should have disabled the Fortan bindings)
If there is something other than the -bind-to-* flags I should be using
to reach the problematic code, let me know.
But based on what I've seen so far, I think we can probably rule out the
compiler as the problem
d be fixed "properly"
(whatever that may equate to) for 1.6.
The way I see it now, it feels like OMPI is getting a definition of
u_char only "by accident".
-Paul
On 2/21/2012 12:16 PM, Paul H. Hargrove wrote:
Building the v1.5 branch on Linux with the Solaris Studio 12.2
w an unknown layer, so num_sockets is
returning 0.
I can poke around more, but does someone want to advise?
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr
in
stdint.h).
I had a look at the trunk and VISUALLY is appears the same problem
exists in:
opal/event/event.h
opal/mca/event/libevent2013/libevent/event.h
However, my testing is currently confined to the v1.5 branch in the
hopes of finally getting the next 1.5.5rc out the door.
-Paul
--
ll the write wrapper.
So I renamed it to something less problematic.
On Feb 21, 2012, at 1:20 AM, Paul H. Hargrove wrote:
And while we are looking at examples/Makefile on Solaris-10, why are
the F77 examples getting built w/ mpif90?
Because w/ the Solaris make setting FC also silently
patch to fix both F77/FC and the "better" ompi_info
queries mentioned in my previous post.
This REPLACES the patch in the previous post.
-Paul
On 2/20/2012 11:36 PM, Paul H. Hargrove wrote:
The addition on Monday of the Java cases to examples/Makefile has
shown that the default "m
grep bindings:cxx:yes >/dev/null; then
I have *also* tested that approach, and it works fine too.
I *did* warn that the introduction of the java bindings would bring
collateral damage.
I just didn't anticipate encountering it personally.
-Paul
--
Paul H. Hargrove
Testing tonight's trunk tarball on the Altix system I have access to
looks fine now.
Thanks, Brian.
-Paul
On 2/20/2012 11:49 AM, Paul H. Hargrove wrote:
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
/mca/io/romio/romio/adio/ad_pvfs2/ad_pvfs2_io_dtype.c
ompi/mca/io/romio/romio/adio/ad_pvfs2/ad_pvfs2_io_list.c
Not sure how much one cares, but I am reporting on the off chance
somebody does want to fix this.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technolog
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,
n-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department
SHOW_HELP_PARSE_TOPIC; }
.*\n { BEGIN(INITIAL); }
On 2/20/2012 3:26 PM, Ralph Castain wrote:
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 f
done to
correct it.
On Feb 19, 2012, at 8:47 PM, Paul H. Hargrove wrote:
I've not checked any other systems, but building the trunk on OpenBSD and
FreeBSD (w/ flex-2.5.4) I see the following:
LEXshow_help_lex.c
"[srcdir]/opal/util/show_help_lex.l", line 65: warning, dangerou
ian
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
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 p
Paul
On 2/20/2012 1:16 PM, Paul H. Hargrove wrote:
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 res
On 2/20/2012 1:26 PM, Brice Goglin wrote:
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
Tests on the virtual node I have access to where that problem report
originated is still not quite right.
There is now a different assertion failing than I had seen before:
lt-linux-libnuma:
/users/phh1
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
laris10 results.
NOTE: this is NOT present in the v1.5 branch (no cmr is required).
-Paul
On 2/20/2012 12:46 PM, Jeffrey Squyres wrote:
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
and I suspect that is the
new problem I am hitting. I hope to know soon.
-Paul
On 2/20/2012 12:41 PM, Jeffrey Squyres wrote:
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.
=dash dash [path_to]/configure [options]
-Paul
On 2/20/2012 5:42 AM, Jeffrey Squyres wrote:
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
macro to handle issues like this, so
it was a fairly easy fix.
Thanks,
Brian
On 2/17/12 4:26 PM, "Paul H. Hargrove"<phhargr...@lbl.gov> wrote:
I've poked enough at the ompi configure magic to *think* I
understand the source of the problem I've seen w/ both tru
fo.cgi/users
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Labora
k_alps.m4: AS_IF([test
"$orte_check_alps_pmi_happy" == "yes" -a "$orte_without_full_support" = 0],
./config/ompi_load_platform.m4:if test "$with_platform" == "" ; then
The $with_platform test breaks configure fairly early on at l
onent fbtl:posix can compile".
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov <mailto:phhargr...@lbl.gov>
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
--
t mentions that the
POSIX draft for LEX leaves such cases undefined.
http://flex.sourceforge.net/manual/Limitations.html
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkele
__hwloc_inline const char *
hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
{
...
}
does it work that way?
Samuel
Yes. That worked!
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
: 1506-277 (S)
Syntax error: possible missing ';' or ','?
make[1]: *** [topology.lo] Error 1
So, we are safer sticking with the current form and ignoring the warning.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research
tribute_pure
+static __hwloc_inline __hwloc_attribute_pure const char *
hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
{
unsigned i;
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-23
_altix_freq'
collect2: ld returned 1 exit status
The configure-generated opal_config.h contains
#define MCA_timer_IMPLEMENTATION_HEADER
"opal/mca/timer/altix/timer_altix.h"
Nothing appears to have been built in BUILDDIR/opal/mca/timer/altix.
However, BUILDDIR/opal/mca/timer/linux has been b
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
--- openmpi-1.7a1r25944/opal/include/opal/types.h~ Fri Feb 17 12:01:41 2012
+++ openmpi
_common_mmap"
opal_crs_base_cleanup_append(self_sm_module->sm_common_mmap->map_path,
false);
^
compilation aborted for
/home/pcp1/phargrov/OMPI/openmpi-1.5-latest-linux-x86-gm2-icc-8.1//openmpi-1.5-latest/ompi/mca/mpool/sm/mpool_sm_module.c
(code 2)
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
tl->error_cb() appears correct on the 1.5 branch (just a
visual inspection).
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
and I thought we had this issue fixed.
I don't know for sure how I missed re-testing the final cut, but can
only guess that I left --disable-visibility in my testing scripts.
-Paul "thorough testing is a double-edged sword" Hargrove
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
As I already discover (see
http://www.open-mpi.org/community/lists/devel/2012/02/10444.php), MacOS
10.4 is NOT listed as a supported platform any longer. So, this message
is really just for the archives.
From "man ld" on a MacOS 10.4 system (x86 or ppc):
MACOSX_DEPLOYMENT_TARGET
and 64 bit (x86_64), with gcc
and Absoft compilers (*).
-Paul
On 2/15/2012 7:24 PM, Paul H. Hargrove wrote:
As a point for discussion, I am going to offer a simple solution:
c) Ignore this for 1.5.5 and raise the minimum MacOS version from 10.4
to 10.5 for ompi 1.6.x and 1.7.x
Any stron
As a point for discussion, I am going to offer a simple solution:
c) Ignore this for 1.5.5 and raise the minimum MacOS version from 10.4
to 10.5 for ompi 1.6.x and 1.7.x
Any strong opinions?
-Paul
On 2/15/2012 10:29 AM, Paul H. Hargrove wrote:
I wanted to note that MacOS 10.4 on *X86* has
wrote:
I don't know if it is a Clang bug, but here's my understanding of the problem.
[...excellent description removed...]
I'm not sure if this is a bug in Clang because I don't know if Clang
should have tried to instantiate create().
Dmitri
--
Paul H. Hargrove
dded it to the trunk.
On Wed, Feb 15, 2012 at 2:17 PM, Paul H. Hargrove <phhargr...@lbl.gov
<mailto:phhargr...@lbl.gov>> wrote:
The following 1-line change resolves the problem for me, and I see
no potential down-side to it:
---
openmpi-1.7a1r25927/opal/mca/event/li
7m/test/util/opal_path_nfs.c 2012-02-16
01:49:18.882418827 +0100
@@ -154,6 +154,7 @@
nfs_tmp[mount_known] = false;
if (0 == strcasecmp (fs, "nfs") ||
+0 == strcasecmp (fs, "nfs4") ||
0 == strcasecmp (fs, "lustre") ||
2012-02-15 14:11:25.183478598 -0800
@@ -4,7 +4,7 @@
*/
#include "opal_config.h"
#include "opal/constants.h"
-#include "config.h"
+#include "libevent/config.h"
#ifdef HAVE_SYS_TYPES_H
#include
-Paul
On 2/15/2012 1:58 PM, Paul H. Hargrove wr
event2013_module.c
-fPIC -DPIC -o .libs/libevent2013_module.o
-Paul
On 2/15/2012 1:16 PM, Paul H. Hargrove wrote:
Thanks, Ralph.
I am a little deficient in the autotools department.
So, I will probably only be able to retest after a new trunk tarball
is generated tonight.
In the me
.h confusion you
report, though - just noting that it built.
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
PIC -shared pmpi_test.c -Iinclude -o libpmpi_test.dylib -Llib
powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
/usr/bin/ld: Undefined symbols:
_MPI_Init
_PMPI_Finalize
collect2: ld returned 1 exit status
-Paul
Thanks!
Matthias
On 12/14/2011 2:51 PM, Paul H. Hargrove wrote:
I've attempted to
On 2/14/2012 10:13 PM, Paul H. Hargrove wrote:
On the linux/mips64el platform I also tried the PathScale 3.3a
compilers on both branches.
On both branches the atomic_*_noinline tests all PASS, which validates
these patches.
On trunk all the tests in test/asm are PASSing.
However
The attached patches fix three problems with the non-inline ASM for MIPS
(and MIPS64EL):
1) ".set rerorder" was placed too early.
This was causing loss of the SLTU instruction in the jump delay
slot which follows the return instruction. Since that SLTU is
used to set the return value,
On 2/14/2012 5:10 PM, Paul H. Hargrove wrote:
I have configured the ompi-trunk (from last night's tarball:
1.7a1r25913) with --without-hwloc.
Having done so, I see the following failure at build time:
CC rmaps_rank_file_component.lo
/home/hargrove/OMPI/openmpi-trunk-linux-mips64el
in the 1.5 branch configured with identical arguments.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
nts to ibv_create_cq],
which performs exactly the sort of test I am warning against.
So, I would encourage somebody to make the effort to reuse the configure
logic Jeff and I developed for hwloc.
In particular look for setting and use of HWLOC_STRICT_ARGS_CFLAGS in
config/hwloc.m4
-Paul
see only 2 problems at this point:
+ known libnuma issues on a "wierd" virtual node - NOT expected to fix
in 1.3.x
+ "make check" failure w/ icc-8.0 on x86/Linux - BUT icc-9.0 and gcc are
both fine on the same node (so probably a compiler bug).
So, I agree this looks &q
/lists/devel/2012/01/10300.php
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
for -m32 with Ubuntu/Sun compilers
- refuse to configure with gccffs
- LANL TLCC2 platform files
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax
That's probably a reflection of the status of the "Open MPI User
Documentation" sub-project :-)
On 2/10/2012 5:12 PM, Jeff Squyres wrote:
FWIW: google analytics indicates that the FAQ and the mailing list archives are
among the most heavily used sections of the web site. :-)
Much better - at least to the extent that users actually read FAQs :-)
-Paul
On 2/10/2012 5:01 PM, Jeff Squyres (jsquyres) wrote:
Check out #220 now; I updated it.
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department
On 2/10/2012 12:21 PM, Jeff Squyres wrote:
On Feb 10, 2012, at 3:14 PM, Paul H. Hargrove wrote:
+ User knows nothing about xen, and thus nothing about virbr0
+ User has a local-only interface (eth8 in my made up example)
+ User reads FAQ entry "220. How do I tell Open MPI which TCP net
On 2/10/2012 12:03 PM, Jeff Squyres wrote:
On Feb 10, 2012, at 1:44 PM, Paul H. Hargrove wrote:
Since the situation described is one where the user didn't know they
could/should disable xen, it is reasonable to think they ALSO don't know they
need to exclude virbr0.
That's what I'm
ompi_cv_cc_fvisibility="yes"
fi
else
ompi_cv_cc_fvisibility="yes"
fi],
[ompi_cv_cc_fvisibility="no"])
])
-Paul
--
Paul H. Hargrove
sure I was testing the right version.)
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
in this respect.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
On 2/10/2012 9:27 AM, Paul H. Hargrove wrote:
I have versions 8.1.032, 9.0.024 and 9.1.042 of the Intel compilers on
a Linux/x86 (32-bit) host.
All three can configure and build hwloc-1.3.2rc1, but all are failing
"make check" in the same way.
What I see is ton(ne)s of linke
clude virbr0. So, I read the question as meaning the
following:
What happens when a user who doesn't know anything about virbr0 does
mpirun --mca btl_tcp_if_exclude lo,eth8
And my guess is "nothing good happens".
-Paul
--
Paul H. Hargrove phhargr...@lb
On 2/9/2012 2:26 PM, Paul H. Hargrove wrote:
We then test if *either* set the variable.
Sort of a double-negative.
One of De Morgan's Laws:
NOT (A AND B) = (NOT A) OR (NOT B)
Applied to give:
NOT (TEST1_FAIL AND TEST2_FAIL)
= (NOT TEST1_FAIL) OR (NOT TEST2_FAIL
y more to this than a need for special-casing the singleton?
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
AC_MSG_CHECKING([for old prototype of sched_setaffinity])
@@ -403,6 +411,9 @@
#define _GNU_SOURCE
#include
]])
+# Restore the CFLAGS if we modified them above
+AS_IF([test "$hwloc_c_vendor" = "ibm"],
+ [CFLAGS=HWLOC_CFLAGS])
AC_MSG_CHECKING([for
On 2/9/2012 4:48 AM, Jeff Squyres wrote:
On Feb 8, 2012, at 6:02 PM, Paul H. Hargrove wrote:
The file config/hwloc_check_vendor.m4 that is present in trunk, is ABSENT in
the 1.3.2rc1 tarball.
There is, correspondingly, no call to _HWLOC_C_COMPILER_VENDOR in hwloc.m4.
Correct -- we hadn't
On 2/8/2012 4:41 PM, Paul H. Hargrove wrote:
I do agree w/ Samuel that the BEST solution is to apply "-qhalt=e"
ONLY to the test(s) where one expects the compiler to through errors
(rather than warnings) for function calls with argument counts which
don't match the
On 2/8/2012 4:43 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit :
On 2/8/2012 4:31 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
Option #4:
CFLAGS='-qhalt=e -qsuppress=1506-077'
Appears to work for me
On 2/8/2012 4:31 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
Option #4:
CFLAGS='-qhalt=e -qsuppress=1506-077'
Appears to work for me for xlc-8.0 and xlc-9.0.
That still looks dangerous to me: we don't know whatever warning
might be added
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
Please test!
http://www.open-mpi.org/software/hwloc/v1.3/
I have access to BG/L, BG/P, Cray-XT and Cray-XE systems.
Are there any tests I could/should consider running on those?
-Paul
--
Paul H. Hargrove phhargr
ine visibility and other
things going quite wrong with various compilers.
The file config/hwloc_check_vendor.m4 that is present in trunk, is
ABSENT in the 1.3.2rc1 tarball.
There is, correspondingly, no call to _HWLOC_C_COMPILER_VENDOR in hwloc.m4.
Am I correct here, or have I missed something?
-Paul
--
On 2/8/2012 1:10 PM, Paul H. Hargrove wrote:
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
* Detect when a compiler such as xlc may not report compile errors
properly, causing some configure checks to be wrong. Thanks to
Paul H. Hargrove for reporting the problem and providing a patch
SS.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
forward or backward progress.
Maybe the sanity check is just different between 1.3 and trunk?
So, I figured I had better report it.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
* Detect when a compiler such as xlc may not report compile errors
properly, causing some configure checks to be wrong. Thanks to
Paul H. Hargrove for reporting the problem and providing a patch.
Looks like I botched this one!
I have added two
On 2/8/2012 11:14 AM, Paul H. Hargrove wrote:
On 2/8/2012 3:25 AM, TERRY DONTJE wrote:
+ Building w/ Solaris Studio 12.2 or 12.3 on Linux x86-64, with
"-m32" required setting LD_LIBRARY_PATH.
Can the LD_LIBRARY_PATH be substituted with a rpath change in LDFLAGS
of the build?
about xlc on MacOS 10.3?
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
et up this way.
This appears to be the default on Ubuntu (checked 3 hosts with 2
different releases).
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
1 - 100 of 313 matches
Mail list logo
