I reran the build as Ralf requested (setting
shlibpath_overrides_runpath=yes in the libtool script).
The build and check were SUCCESSful!
I have provided Ralf with the requested files off-list.
-Paul
Ralf Wildenhues wrote:
* Paul H. Hargrove wrote on Fri, Aug 27, 2010 at 03:54:54AM CEST:
I have built both 1.4.3rc1 and 1.5rc5 using the 3.2 PathScale compilers.
I did not encounter the problem Larry reported, but there are (at least)
2 differences between my build and Larry's
1) I didn't pass and explicit {C,CXX,F,FC}FLAGS
2) My pathcc install is using the gcc4 toolchain, not
The one line change below fixes a problem with the portable_platform
header with respect to PathScale compilers that lack a patchlevel. For
instance, the 3.2 version I have defines __PATHCC_PATCHLEVEL__ to be empty.
I am the maintainer of GASNet's portable_platform.h from which Open
MPI's
You can always disable vampir trace in OMPI:
./configure --enable-contrib-no-build=vt
That will avoid building this optional component and therefore you won't run
into this compiler issue.
On Aug 27, 2010, at 5:18 PM, Larry Baker wrote:
> The PathScale 3.2 C++ compiler segment faults for
Among the tests I conducted but did not report was a successful build of
1.5rc5 with the PathScale "3.2.99" compilers.
$ pathcc --version
PathScale(TM) Compiler Suite: Version 3.2.99
Built on: 2009-08-21 13:23:57 -0500
Thread model: posix
GNU gcc version 4.2.0 (PathScale 3.2.99 driver)
The PathScale 3.2 C++ compiler segment faults for optimization levels
higher than -O1 (-O2 is the default). This is for OpenMPI 1.4.2 — my
first attempt to compile using the PathScale compilers. I could not
find any -WOPT options to eliminate the error. I don't understand the
current
Jeff,
Sure, I need to register to file the tickets.
I have not had a chance yet. I will try to look at them first thing next week.
Scott
On Aug 27, 2010, at 2:41 PM, Jeff Squyres wrote:
> Scott --
>
> Can you file tickets for this against 1.4 and 1.5? These should probably be
> blockers.
>
Has anybody tested runs of the current release candidates on Quadrics Elan4?
I have successfully built for Elan4 on a system with the headers and
libs, but no hardware and thus no runs.
I can try running on a cluster with actual Quadrics hardware nobody else
has done so. Let me know.
-Paul
All instances will be fixed on the SVN trunk in a commit coming in a few hours
(delaying autogen-worthy changes during the business day). Shame on us for
using AS_VAR_GET.
CMR's for v1.5 coming tonight; CMR for v1.4 (because it's a different patch) is
here:
Rolf,
Thanks, your explanation makes sense (intersection of ILP32 and V9 ISA
yields V8+ ABI).
When updating the README, please also consider my posting regarding the
recommended flags for the Sun C compiler, which are causing warnings
from recent Sun compilers:
* Paul H. Hargrove wrote on Fri, Aug 27, 2010 at 03:54:54AM CEST:
> >I am now looking at using IBM's XLC compilers for ILP32 builds on
> >the same Linux/PPC64 platform for which I've reported some
> >XLC/LP64 bugs.
> >
> >What I find now is that "make check" is failing with the loader
> >unable to
Paul, I believe you are right. I was referencing information from here
http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html From this site, I
also read the following:
"With -mv8plus, GCC generates code for the SPARC-V8+ ABI. The difference
from the V8 ABI is that the global and out
As per the RFC below, I'll begin rolling these changes into the trunk over the
next week.
> WHAT: Begin the process of introducing threads and thread safety into ORTE
>
> WHY: ORTE is becoming increasingly dependent on thread-safe operations
> (lock, cond_wait, unlock). However, OPAL
I have found a system that is triggering two (new as far as I can tell)
failure modes in opal_path_nfs().
This is a Linux/PPC64 host, but NOT the BG/P front-end I've been
reporting other issues with.
This is also with gcc, not XLC. So, this is a "normal" Linux/PPC system.
I'll provide
14 matches
Mail list logo
