Ralph,
You get it right.
The latest nightly tarball shoul work out of the box.
(well, -m64 must be passed manually, but this is not related whatsoever to the
issue discussed here)
Cheers,
Gilles
"Jeff Squyres (jsquyres)" wrote:
>Paul --
>
>The __sun macro check is now in the OMPI 1.8 tree, an
Results of tests described below:
1) SEGV in hwloc - will report later
2) PASS
3) PASS
So, both -D_REENTRANT or -mt are working for me IF added both the CFLAGS
and wrapper-cflags.
-Paul
On Tue, Dec 16, 2014 at 10:56 PM, Paul Hargrove wrote:
>
> I've queued 3 tests:
>
> 1) openmpi-v1.8.3-272-g4
I did run the nightly and it SEGVs in hwloc!
I will provide more info when I am able.
-Paul
On Tue, Dec 16, 2014 at 10:59 PM, Gilles Gouaillardet <
gilles.gouaillar...@iferc.org> wrote:
>
> Thanks Paul !
>
> imho the first test is useless since it does not include the commit that
> sets the -D_RE
Turns out that this problem was caused by not having a Fortran compiler. I
fixed that in
https://github.com/open-mpi/ompi-release/commit/b90c8142d343b12cbcc1023cb767801ea2d567a4.
There's still 2 other minor problems (a cleanfile and a condition source
include); working on those...
On Dec 17,
I was unable to reproduce this on rhel6 like with both stock gcc 4.8.x and gcc
4.9.1
Was the libtool updated on the ompi server ?
2.4.2 works fine for me
Cheers,
Gilles
Ralph Castain wrote:
>It is breaking the automated nightly tarball build - see the error email that
>came out earlier:
>
>
It is breaking the automated nightly tarball build - see the error email
that came out earlier:
PPFC libmpi_mpifh_sizeof_la-sizeof-mpif08-pre-1.8.4_f.lo
libtool: compile: unrecognized option `-I../../../../ompi/mpi/
fortran/use-mpi-tkr'
libtool: compile: Try `libtool --help' for more informat
Ralph,
what goes wrong ?
(e.g. which command ?)
and which compiler (e.g. gcc < 4.9.1 ?) are you using ?
Cheers,
Gilles
On 2014/12/17 17:30, Ralph Castain wrote:
> I'm afraid I cannot generate a new rc, nor will there be a new 1.8 nightly
> tarball as (ahem) Jeff's fortran commit broke the buil
I'm afraid I cannot generate a new rc, nor will there be a new 1.8 nightly
tarball as (ahem) Jeff's fortran commit broke the build system. I tried to
figure out a fix, but am too tired to get it right.
So I'm afraid we are stuck for the moment until Jeff returns in the morning
and fixes the proble
Thanks Paul !
imho the first test is useless since it does not include the commit that
sets the -D_REENTRANT CFLAGS on solaris/solarisstudio
https://github.com/open-mpi/ompi-release/commit/ac8b84ce674b958dbf8c9481b300beeef0548b83
Cheers,
Gilles
On 2014/12/17 15:56, Paul Hargrove wrote:
> I've q
I've queued 3 tests:
1) openmpi-v1.8.3-272-g4e4f997
2) openmpi-v1.8.4rc4 + adding -D_REENTRANT to CFLAGS and wrapper-cflags
3) openmpi-v1.8.4rc4 + adding -mt to CFLAGS and wrapper-cflags
I hope to be able to login and collect the results around noon pacific time
on Wed.
-Paul
On Tue, Dec 16, 20
Paul,
i understand, i will now work on a better way to figure out the required
flags
the latest nightly snapshot does not include the commit i mentionned,
and i think
it is worth giving it a try (to be 100.0% sure ...)
can you please do that tomorrow ?
in the mean time, if we (well Ralph indeed
Gilles,
If I have done my testing correctly (not 100% sure) then adding
"-D_REENTRANT" was NOT sufficient, where "-mt" was.
I can at least test 1 tarball with one set of configure args each evening.
Anything more than that I cannot commit to.
My scripts are capable of grabbing the v1.8 nightly i
Ralph,
i think that will not work.
here is the full story :
once upon a time, on solaris, we did not try to compile pthread'ed app
without any special parameters.
that was a minor annoyance on solaris 10 with old gcc : configure passed
a flag (-pthread if i remember correctly)
that was not suppo
Ralph,
No change with the patch you supplied.
The test that uses the "pflags" set by your patch is guarded by the value
of ompi_pthread_c_success.
So, I think there must be some other patch needed to the body
of OMPI_INTL_POSIX_THREADS_PLAIN_C to even reach the code changed by the
patch you sent
Hi Paul
Can you try the attached patch? It would require running autogen, I fear.
Otherwise, I can add it to the tarball.
Ralph
On Tue, Dec 16, 2014 at 9:59 PM, Paul Hargrove wrote:
>
> Gilles,
>
> The 1.8.3 test works where the 1.8.4rc4 one fails with identical configure
> arguments.
>
> Whil
Gilles,
The 1.8.3 test works where the 1.8.4rc4 one fails with identical configure
arguments.
While it may be overkill, I configured 1.8.4rc4 with
CFLAGS="-m64 -mt" --with-wrapper-cflags="-m64 -mt" \
LDFLAGS="-mt" --with-wrapper-ldflags="-mt"
The resulting run worked!
So, I very strongly
My 1.8.3 build has not completed.
HOWEVER, I can already see a key difference in the configure step.
In 1.8.3 "-mt" was added AUTOMATICALLY to CFLAGS by configure:
checking if C compiler and POSIX threads work as is... no - Solaris, not
checked
checking if C++ compiler and POSIX threads work as i
Paul,
i do not think -lpthread is passed automatically to LDFLAGS on Solaris,
so you might have to do it manually as well
i never used
--with-wrapper-cflags
before, so i'd rather invite you to
mpicc -show
to make sure the right flags are passed at the right place when the app
is built
Cheers,
Gilles,
I am running the build of 1.8.3 first.
As you suggest, I will only try without -m64 if 1.8.3 runs with it.
Regarding "-mt" my understanding from "man cc" is that it has a DUAL
function:
1) Passes -D_REENTRANT to the preprocess stage (if any)
2) Passes "the right flags" to the linker stage
Thanks Paul,
if 1.8.3 with -m64 and the same compilers runs fine, then please do not
bother running 1.8.4rc4 without -m64.
/* i understand you are busy and i hardly believe -m64 is the root cause */
a regression i can think of involves the flags we use for pthreads :
for bad reasons, we initially
Gilles,
First, please note that prior tests of 1.8.3 ran with no problems on these
hosts.
So, I *think* this problem is a regression.
However, I am not 100% certain that this *exact* configuration was tested.
So, I am RE-running a test of 1.8.3 now to be absolutely sure if this is a
regression.
I
Thanks Paul,
Are you invoking mpirun on pcp-j-20 ?
If yes, what does
getent hosts pcp-j-20
says ?
BTW, did you try without -m64 ?
Does the following work
ping/ssh 172.18.0.120
Honestly, this output makes very little sense to me, so i am asking way too
much info hoping i can reproduce this issu
22 matches
Mail list logo
