FYI - the proposed 'here-doc' solution below didn't work for me, it
produced an error. Neither did printf. When I used printf, only the
first arg was passed along:
#!/bin/bash
realcmd=/usr/pppl/pgi/17.3/linux86-64/17.3/bin/pgcc.real
echo "original args: $@"
newargs=$(printf -- "$@" | sed s/-pthread//g)
echo "new args: $newargs"
#$realcmd $newargs
exit
$ pgcc -tp=x64 -fast conftest.c
original args: -tp=x64 -fast conftest.c
new args: -tp=x64
Any ideas what I might be doing wrong here?
So, my original echo "" "$@" solution works, and another colleague also
suggested this expressions, which appears to work, too:
newargs=${@/-pthread/}
Although I don't know how portable that is. I'm guessing that's very
bash-specific syntax.
Prentice
On 04/03/2017 04:26 PM, Prentice Bisbal wrote:
A coworker came up with another idea that works, too:
newargs=sed s/-pthread//g <<EOF
$@
EOF
That should work, too, but I haven't test it.
Prentice
On 04/03/2017 04:11 PM, Andy Riebs wrote:
Try
$ printf -- "-E" ...
On 04/03/2017 04:03 PM, Prentice Bisbal wrote:
Okay. the additional -E doesn't work,either. :(
Prentice Bisbal Lead Software Engineer Princeton Plasma Physics
Laboratory http://www.pppl.gov
On 04/03/2017 04:01 PM, Prentice Bisbal wrote:
Nevermind. A coworker helped me figure this one out. Echo is
treating the '-E' as an argument to echo and interpreting it
instead of passing it to sed. Since that's used by the configure
tests, that's a bit of a problem, Just adding another -E before $@,
should fix the problem.
Prentice
On 04/03/2017 03:54 PM, Prentice Bisbal wrote:
I've decided to work around this problem by creating a wrapper
script for pgcc that strips away the -pthread argument, but my sed
expression works on the command-line, but not in the script. I'm
essentially reproducing the workaround from
https://www.open-mpi.org/community/lists/users/2009/04/8724.php.
Can anyone see what's wrong with my implementation the workaround?
It's a very simple sed expression. Here's my script:
#!/bin/bash
realcmd=/path/to/pgcc
echo "original args: $@"
newargs=$(echo "$@" | sed s/-pthread//)
echo "new args: $newargs"
#$realcmd $newargs
exit
And here's what happens when I run it:
/path/to/pgcc -E conftest.c
original args: -E conftest.c
new args: conftest.c
As you can see, the -E argument is getting lost in translation. If
I add more arguments, it works fine:
/path/to/pgcc -A -B -C -D -E conftest.c
original args: -A -B -C -D -E conftest.c
new args: -A -B -C -D -E conftest.c
It only seems to be a problem when -E is the first argument:
$ /path/to/pgcc -E -D -C -B -A conftest.c
original args: -E -D -C -B -A conftest.c
new args: -D -C -B -A conftest.c
Prentice
On 04/03/2017 02:24 PM, Aaron Knister wrote:
To be thorough couldn't one replace -pthread in the slurm .la
files with -lpthread? I ran into this last week and this was the
solution I was thinking about implementing. Having said that, I
can't think of a situation in which the -pthread/-lpthread
argument would be required other than linking against statically
compiled SLURM libraries and even then I'm not so sure about that.
-Aaron
On 4/3/17 1:46 PM, �ke Sandgren wrote:
We build slurm with GCC, drop the -pthread arg in the .la files,
and
have never seen any problems related to that. And we do build
quite a
lot of code. And lots of versions of OpenMPI with multiple
different
compilers (and versions).
On 04/03/2017 04:51 PM, Prentice Bisbal wrote:
This is the second suggestion to rebuild Slurm
The other from �ke Sandgren, who recommended this:
This usually comes from slurm, so we always do
perl -pi -e 's/-pthread//' /lap/slurm/${version}/lib/libpmi.la
/lap/slurm/${version}/lib/libslurm.la
when installing a new slurm version. Thus no need for a fakepg
wrapper.
I don't really have the luxury to rebuild Slurm at the moment.
How would
I rebuild Slurm to change this behavior? Is rebuilding Slurm
with PGI
the only option to fix this in slurm, or use �ke's suggestion
above?
If I did use �ke's suggestion above, how would that affect the
operation
of Slurm, or future builds of OpenMPI and any other software
that might
rely on Slurm, particulary with regards to building those apps
with
non-PGI compilers?
Prentice
On 04/03/2017 10:31 AM, Gilles Gouaillardet wrote:
Hi,
The -pthread flag is likely pulled by libtool from the slurm
libmpi.la
<http://libmpi.la> and/or libslurm.la <http://libslurm.la>
Workarounds are
- rebuild slurm with PGI
- remove the .la files (*.so and/or *.a are enough)
- wrap the PGI compiler to ignore the -pthread option
Hope this helps
Gilles
On Monday, April 3, 2017, Prentice Bisbal <pbis...@pppl.gov
<mailto:pbis...@pppl.gov>> wrote:
Greeting Open MPI users! After being off this list for
several
years, I'm back! And I need help:
I'm trying to compile OpenMPI 1.10.3 with the PGI compilers,
version 17.3. I'm using the following configure options:
./configure \
--prefix=/usr/pppl/pgi/17.3-pkgs/openmpi-1.10.3 \
--disable-silent-rules \
--enable-shared \
--enable-static \
--enable-mpi-thread-multiple \
--with-pmi=/usr/pppl/slurm/15.08.8 \
--with-hwloc \
--with-verbs \
--with-slurm \
--with-psm \
CC=pgcc \
CFLAGS="-tp x64 -fast" \
CXX=pgc++ \
CXXFLAGS="-tp x64 -fast" \
FC=pgfortran \
FCFLAGS="-tp x64 -fast" \
2>&1 | tee configure.log
Which leads to this error from libtool during make:
pgcc-Error-Unknown switch: -pthread
I've searched the archives, which ultimately lead to this
work
around from 2009:
https://www.open-mpi.org/community/lists/users/2009/04/8724.php
<https://www.open-mpi.org/community/lists/users/2009/04/8724.php>
Interestingly, I participated in the discussion that lead
to that
workaround, stating that I had no problem compiling Open
MPI with
PGI v9. I'm assuming the problem now is that I'm specifying
--enable-mpi-thread-multiple, which I'm doing because a user
requested that feature.
It's been exactly 8 years and 2 days since that workaround
was
posted to the list. Please tell me a better way of dealing
with
this issue than writing a 'fakepgf90' script. Any
suggestions?
--
Prentice
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
<https://rfd.newmexicoconsortium.org/mailman/listinfo/users>
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
