[OMPI users] Compiler error with PGI: pgcc-Error-Unknown switch: -pthread

Discussion:

Prentice Bisbal

2017-04-03 14:20:38 UTC

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

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

Åke Sandgren

2017-04-03 14:30:26 UTC

Permalink

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.

Post by Prentice Bisbal
Greeting Open MPI users! After being off this list for several years,
I'm trying to compile OpenMPI 1.10.3 with the PGI compilers, version
./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
pgcc-Error-Unknown switch: -pthread
I've searched the archives, which ultimately lead to this work around
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?

--
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: ***@hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-580 14
Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se

Gilles Gouaillardet

2017-04-03 14:31:58 UTC

Permalink

Hi,

The -pthread flag is likely pulled by libtool from the slurm libmpi.la
and/or 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

Greeting Open MPI users! After being off this list for several years, I'm
I'm trying to compile OpenMPI 1.10.3 with the PGI compilers, version 17.3.
./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
pgcc-Error-Unknown switch: -pthread
I've searched the archives, which ultimately lead to this work around from
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
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Prentice Bisbal

2017-04-03 14:51:39 UTC

Permalink

This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

Post by Ãke Sandgren
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
Greeting Open MPI users! After being off this list for several
I'm trying to compile OpenMPI 1.10.3 with the PGI compilers,
./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
pgcc-Error-Unknown switch: -pthread
I've searched the archives, which ultimately lead to this work
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
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
<https://rfd.newmexicoconsortium.org/mailman/listinfo/users>
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Åke Sandgren

2017-04-03 17:46:18 UTC

Permalink

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).

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

--
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: ***@hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-580 14
Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se

Aaron Knister

2017-04-03 18:24:24 UTC

Permalink

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

Post by Ãke Sandgren
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).

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

--
Aaron Knister
NASA Center for Climate Simulation (Code 606.2)
Goddard Space Flight Center
(301) 286-2776

Prentice Bisbal

2017-04-03 19:54:03 UTC

Permalink

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

Post by Aaron Knister
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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Prentice Bisbal

2017-04-03 20:01:12 UTC

Permalink

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

Post by Prentice Bisbal
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?
#!/bin/bash
realcmd=/path/to/pgcc
echo "new args: $newargs"
#$realcmd $newargs
exit
/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
/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
$ /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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Prentice Bisbal

2017-04-03 20:03:42 UTC

Permalink

Okay. the additional -E doesn't work,either. :(

Prentice Bisbal Lead Software Engineer Princeton Plasma Physics
Laboratory http://www.pppl.gov

Post by Prentice Bisbal
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
Prentice

Post by Prentice Bisbal
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?
#!/bin/bash
realcmd=/path/to/pgcc
echo "new args: $newargs"
#$realcmd $newargs
exit
/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
/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
$ /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

Post by Aaron Knister
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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Andy Riebs

2017-04-03 20:11:56 UTC

Permalink

Try
$ printf -- "-E" ...

Post by Prentice Bisbal
Okay. the additional -E doesn't work,either. :(
Prentice Bisbal Lead Software Engineer Princeton Plasma Physics
Laboratory http://www.pppl.gov

Post by Prentice Bisbal
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
problem.
Prentice

Post by Prentice Bisbal
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?
#!/bin/bash
realcmd=/path/to/pgcc
echo "new args: $newargs"
#$realcmd $newargs
exit
/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
/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
$ /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

Post by Aaron Knister
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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

--
Andy Riebs
***@hpe.com
Hewlett-Packard Enterprise
High Performance Computing Software Engineering
+1 404 648 9024
My opinions are not necessarily those of HPE
May the source be with you!

Prentice Bisbal

2017-04-03 20:26:48 UTC

Permalink

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

Post by Andy Riebs
Try
$ printf -- "-E" ...

Post by Prentice Bisbal
Okay. the additional -E doesn't work,either. :(
Prentice Bisbal Lead Software Engineer Princeton Plasma Physics
Laboratory http://www.pppl.gov

Post by Prentice Bisbal
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,
fix the problem.
Prentice

Post by Prentice Bisbal
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?
#!/bin/bash
realcmd=/path/to/pgcc
echo "new args: $newargs"
#$realcmd $newargs
exit
/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
/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
$ /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

Post by Aaron Knister
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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Prentice Bisbal

2017-04-03 21:07:49 UTC

Permalink

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

Post by Prentice Bisbal
newargs=sed s/-pthread//g <<EOF
EOF
That should work, too, but I haven't test it.
Prentice

Post by Andy Riebs
Try
$ printf -- "-E" ...

Post by Prentice Bisbal
Okay. the additional -E doesn't work,either. :(
Prentice Bisbal Lead Software Engineer Princeton Plasma Physics
Laboratory http://www.pppl.gov

Post by Prentice Bisbal
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
should fix the problem.
Prentice

Post by Prentice Bisbal
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?
#!/bin/bash
realcmd=/path/to/pgcc
echo "new args: $newargs"
#$realcmd $newargs
exit
/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
/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
$ /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

Post by Aaron Knister
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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

Post by Ãke Sandgren
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
Greeting Open MPI users! After being off this list for several
I'm trying to compile OpenMPI 1.10.3 with the PGI compilers,
./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
pgcc-Error-Unknown switch: -pthread
I've searched the archives, which ultimately lead to this work
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
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
<https://rfd.newmexicoconsortium.org/mailman/listinfo/users>
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Reuti

2017-04-03 21:14:46 UTC

Permalink

Post by Prentice Bisbal
#!/bin/bash
realcmd=/usr/pppl/pgi/17.3/linux86-64/17.3/bin/pgcc.real
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?
Although I don't know how portable that is. I'm guessing that's very bash-specific syntax.
Prentice

Post by Prentice Bisbal
newargs=sed s/-pthread//g <<EOF
EOF
That should work, too, but I haven't test it.
Prentice

Post by Andy Riebs
Try
$ printf -- "-E" ...

Post by Prentice Bisbal
Okay. the additional -E doesn't work,either. :(
Prentice Bisbal Lead Software Engineer Princeton Plasma Physics Laboratory http://www.pppl.gov

Post by Prentice Bisbal
Prentice

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

Post by Prentice Bisbal
This is the second suggestion to rebuild Slurm

Post by Ãke Sandgren
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

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Matt Thompson

2017-04-03 22:24:02 UTC

Permalink

Coming in near the end here. I've had "fun" with PGI + Open MPI + macOS
(and still haven't quite solved it, see:
https://www.mail-archive.com/***@lists.open-mpi.org//msg30865.html, still
unanswered!) The solution that PGI gave me, and which seems the magic sauce
on macOS is to use a siterc file (
http://www.pgroup.com/userforum/viewtopic.php?p=21105#21105):

=================================
siterc for gcc commands PGI does not support
=================================
switch -ffast-math is hide;

switch -pipe is hide;

switch -fexpensive-optimizations is hide;

switch -pthread is
append(LDLIB1= -lpthread);

switch -qversion is
early
help(Display compiler version)
helpgroup(overall)
set(VERSION=YES);

switch -Wno-deprecated-declarations is hide;

switch -flat_namespace is hide;
====================================

If you use that, -pthread is "rerouted" to append -lpthread. You might try
that and see if that helps. Since you are on Linux (I assume?), then you
should be able to proceed as you shouldn't encounter the libtool
bug/issue/*shrug* that is breaking macOS use.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Prentice Bisbal
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

bash-specific syntax.

Post by Prentice Bisbal
Prentice

Post by Prentice Bisbal
newargs=sed s/-pthread//g <<EOF
EOF
That should work, too, but I haven't test it.
Prentice

Post by Andy Riebs
Try
$ printf -- "-E" ...

Post by Prentice Bisbal
Okay. the additional -E doesn't work,either. :(
Prentice Bisbal Lead Software Engineer Princeton Plasma Physics

Laboratory http://www.pppl.gov