Thanks Jeff, and all; I will stick to the GNU compilers for now.
On Fri, Mar 9, 2012 at 7:05 AM, Jeffrey Squyres wrote:
> I talked to Brian about this, and he agrees with Nathan: don't use PGI on the
> Cray (I'm acting as an intermediary here -- I don't care about the Cray
> platform at all :-)
The opal_atomic_swap_64 function is always supposed to be inlined or not be
present at all. However, if not present then it shouldn't be used (as no atomic
on 64 bits data are supported by the architecture).
george.
On Mar 6, 2012, at 12:39 , Nathan Hjelm wrote:
> I think the problem is that
I talked to Brian about this, and he agrees with Nathan: don't use PGI on the
Cray (I'm acting as an intermediary here -- I don't care about the Cray
platform at all :-) ).
They have always used GNU and it works fine.
That being said, there may well be something broken with our non-inlined
ass
I think the problem is that it is trying to inline opal_atomic_swap_64 (when it
shouldn't with PGI). I am working on an improved mpool/rcache (w/o kernel
assistance) solution at the moment but when I am done I can take a look.
-Nathan
On Tue, 6 Mar 2012, Jeffrey Squyres wrote:
I'm afraid tha
I'm afraid that I have neither a Cray nor the PGI compiler, so I'm not in a
good position to help here.
Would someone with the PGI compiler give the trunk a whirl to see if disabling
the CXX inline assembly for PGI broke something? I'd be a little surprised,
since we already had it disabled fo
I pulled fresh copy of the dev trunk, and tried building. It did not
change anything - I am still getting the same error:
../../../ompi/.libs/libmpi.so: undefined reference to
`opal_atomic_swap_64'
GNU version still builds fine.
On Tue, Mar 6, 2012 at 5:38 AM, Jeffrey Squyres wrote:
> I disable
I disabled C++ inline assembly for PGI (we already had C inline assembly for
PGI).
So I don't think this should have caused a new error... should it?
On Mar 5, 2012, at 10:21 AM, Nathan Hjelm wrote:
> Try pulling a fresh trunk. Jeff made a recent commit that may be relevant.
> Something about
Try pulling a fresh trunk. Jeff made a recent commit that may be relevant.
Something about inline assembly being broken on PGI (I personally wouldn't
recommend using that compiler unless you are using fortran).
-Nathan
On Sun, 4 Mar 2012, Abhinav Sarje wrote:
The same options/configuration i
The same options/configuration in the GNU environment (compiler
version 4.6.1) builds smoothly. PGI env still gives the aforementioned
error. Has anyone experienced similar problem? May be some more flags
need to be set for PGI?
On Sat, Mar 3, 2012 at 10:58 PM, Abhinav Sarje wrote:
> Hi, I am t
Hi, I am trying to compile 64 bits.
On Fri, Mar 2, 2012 at 11:48 PM, George Bosilca wrote:
> Something is definitively weird in your compilation environment.
>
> The "undefined" function is defined in atomic_impl.h as a static inline
> (static inline int64_t opal_atomic_swap_64(volatile int64_t
Something is definitively weird in your compilation environment.
The "undefined" function is defined in atomic_impl.h as a static inline (static
inline int64_t opal_atomic_swap_64(volatile int64_t *addr,…). So either the
compiler should have complained during compilation, or it should be inlined
I'm going to have to defer this to those who regularly build on Crays...
Sandia / LANL?
On Mar 2, 2012, at 12:12 AM, Abhinav Sarje wrote:
> Hi again,
>
> I just tried building afresh -> svn co, autogen, configure, make. And
> it failed at the same point as before:
CCLD ompi_info
.
Hi again,
I just tried building afresh -> svn co, autogen, configure, make. And
it failed at the same point as before:
>>> CCLD ompi_info
>>> ../../../ompi/.libs/libmpi.so: undefined reference to `opal_atomic_swap_64'
Any more ideas/fixes?
Thanks all.
Abhinav.
On Fri, Mar 2, 2012 at 8:14 AM,
yes, I did a full autogen, configure, make clean and make all
On Thu, Mar 1, 2012 at 10:03 PM, Jeffrey Squyres wrote:
> Did you do a full autogen / configure / make clean / make all ?
>
>
> On Mar 1, 2012, at 8:53 AM, Abhinav Sarje wrote:
>
>> Thanks Ralph. That did help, but only till the next
Did you do a full autogen / configure / make clean / make all ?
On Mar 1, 2012, at 8:53 AM, Abhinav Sarje wrote:
> Thanks Ralph. That did help, but only till the next hurdle. Now the
> build fails at the following point with an 'undefined reference':
> ---
> Making all in tools/ompi_info
Thanks Ralph. That did help, but only till the next hurdle. Now the
build fails at the following point with an 'undefined reference':
---
Making all in tools/ompi_info
make[2]: Entering directory
`/global/u1/a/asarje/hopper/openmpi-dev-trunk/build/ompi/tools/ompi_info'
CC ompi_info.o
You need to update your source code - this was identified and fixed on Wed.
Unfortunately, our trunk is a developer's environment. While we try hard to
keep it fully functional, bugs do occasionally work their way into the code.
On Mar 1, 2012, at 1:37 AM, Abhinav Sarje wrote:
> Hi Nathan,
>
>
Hi Nathan,
I tried building on an internal login node, and it did not fail at the
previous point. But, after compiling for a very long time, it failed
while building libmpi.la, with a multiple definition error:
--
...
CC mpiext/mpiext.lo
CC mpi/f77/base/mpi_f77_base_libmpi_f77_
On Mon, 27 Feb 2012, Abhinav Sarje wrote:
Hi Nathan, Gus, Manju,
I got a chance to try out the XE6 support build, but with no success.
First I was getting this error: "PGC-F-0010-File write error occurred
(temporary pragma .s file)". After searching online about this error,
I saw that there i
Hi Abhinav
> "-march=amdfam10"
AFAIK, this is a gcc/gfortran flag not PGI.
Have you tried instead -tp=shanghai-64 [of whatever AMD processor you have
that is supported by PGI].
'man pgcc' will tell all possible '-tp' values.
I don't have any idea about the orte build problem with alps.
Gus Corr
Looks like you need to add --with-alps= to your configure line.
On Feb 27, 2012, at 10:29 PM, Abhinav Sarje wrote:
> Hi Nathan, Gus, Manju,
>
> I got a chance to try out the XE6 support build, but with no success.
> First I was getting this error: "PGC-F-0010-File write error occurred
> (tempor
Hi Nathan, Gus, Manju,
I got a chance to try out the XE6 support build, but with no success.
First I was getting this error: "PGC-F-0010-File write error occurred
(temporary pragma .s file)". After searching online about this error,
I saw that there is a patch at
"https://svn.open-mpi.org/trac/omp
contrib/platform/lanl/cray-xe6 is within the Open MPI trunk. It contains
platform files for an optimized and a debug build (for configure --platform).
-Nathan
On Thu, 16 Feb 2012, Abhinav Sarje wrote:
Hi again,
Could you tell me the complete path of the svn repo? I think I am
missing somethi
Hi yet again,
Nathan, nevermind my previous email. I found the svn location. I will
give it a try now.
Thanks!
Abhinav.
On Thu, Feb 16, 2012 at 12:00 PM, Abhinav Sarje wrote:
> Hi again,
>
> Could you tell me the complete path of the svn repo? I think I am
> missing something there. Also, can I
Hi again,
Could you tell me the complete path of the svn repo? I think I am
missing something there. Also, can I checkout this version
anonymously, or do I need a dev account?
Thanks,
Abhinav.
On Thu, Feb 16, 2012 at 11:52 AM, Abhinav Sarje wrote:
> Hi Nathan,
>
> I had earlier tried to compile
Hi Nathan,
I had earlier tried to compile OpenMPI with just PGI compilers
(without cray wrapper), but with that my code was not able to run on
the compute nodes of the cray cluster (it just ran on the MOM node).
Therefore I have been trying to compiler OpenMPI with the cray
wrappers.
I will check
Abhinav, you shouldn't be using the cray wrappers to build Open MPI or anything
linked against Open MPI. The Cray wrappers will automatically include lots of
stuff you don't want. Use pgcc, pgcc, or icc directly. You shouldn't have any
trouble running in parallel with either aprun or mpirun (or
Hi Gus,
I am building using the cray wrappers over the PGI compilers, which
gives the errors. I tried building without the cray wrappers, but then
it does not run in parallel on the XE6 system I am using. I am going
to try the latest nightly build.
Abhinav.
On Wed, Feb 15, 2012 at 12:22 PM, Gust
On Feb 15, 2012, at 1:58 PM, Abhinav Sarje wrote:
> Hi Gus,
> I have not added any flags that include static, but when I do a
> verbose compilation output for the point where error occurs, I see
> that there are some -Bstatic flags. I tried to manually remove the
> -Bstatic included just before t
Hi Gus,
I have not added any flags that include static, but when I do a
verbose compilation output for the point where error occurs, I see
that there are some -Bstatic flags. I tried to manually remove the
-Bstatic included just before the libopen-pal.so library, and that
particular line then compi
Can you try the latest 1.5 nightly tarball?
We've upgraded the autotools in the nightlies, but have not yet rolled a new rc.
http://www.open-mpi.org/nightly/v1.5/
On Feb 15, 2012, at 12:18 AM, Abhinav Sarje wrote:
> Hi Jeff,
>
> With the latest 1.5.5rc also I am getting the same error:
>
Hi Abhinav
Did you add to your compiler flags -Bstatic [or perhaps -static],
or any optimization flags that may include -Bstatic/-static?
Check also the compiler configuration, and any possible user customization
[~/.mypggcc and friends] to see if -Bstatic is there, maybe inadvertently, and
is s
Hi Gus, I had tried with the -noswitcherror flags, which removed the
'unknown-switch' error, but then I am still getting the "attempted
static link of dynamic object" error as I reported earlier.
Thanks.
On Fri, Feb 10, 2012 at 5:57 AM, Gustavo Correa wrote:
> Hi Abhinav
>
> Setting CC='pgcc --n
Hi Jeff,
With the latest 1.5.5rc also I am getting the same error:
-
make[2]: Entering directory
`/global/u1/a/asarje/hopper/openmpi-1.5.5rc2r25924-pgi/opal/tools/wrappers'
CC opal_wrapper.o
CCLD opal_wrapper
/usr/bin/ld: attempted static link of dynamic object
`../../../opal/.li
We literally just upgraded the version of autotools on the 1.5 nightly tarballs
(i.e., what will become 1.5.5).
Could you try the most recent 1.5.5 nightly snapshot?
http://www.open-mpi.org/nightly/v1.5/
On Feb 10, 2012, at 8:57 AM, Gustavo Correa wrote:
> Hi Abhinav
>
> Setting CC='pgcc
Hi Abhinav
Setting CC='pgcc --noswitcherror', FC='pgfortran --noswitcherror', etc, may
prevent the
error message [but not sure it will prevent any actual and unreported error].
Check details with 'man pgfortran'.
I hope this helps,
Gus Corea
.
On Feb 10, 2012, at 2:03 AM, Abhinav Sarje wrote
I tried with 1.5.4 and same compilers, and got the exact same error.
I also tried PGI version 11.10.0, and got the same thing.
On Wed, Feb 8, 2012 at 3:04 AM, Jeff Squyres (jsquyres)
wrote:
> Can you try building 1.5.4 with the same compilers?
>
> Sent from my phone. No type good.
>
> On Feb 7,
Can you try building 1.5.4 with the same compilers?
Sent from my phone. No type good.
On Feb 7, 2012, at 3:14 PM, "Abhinav Sarje" wrote:
> I am trying to build open-mpi 1.4.4 (latest stable from open-mpi.org)
> using PGI compilers on a cray platform. PGI compilers' version is
> 11.9.0. I get t
I am trying to build open-mpi 1.4.4 (latest stable from open-mpi.org)
using PGI compilers on a cray platform. PGI compilers' version is
11.9.0. I get the following error while building:
-
Making all in tools/wrappers
make[2]: Entering directory `{my_installation_
39 matches
Mail list logo
