Discussion:
[OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS
Matt Thompson
2016-11-28 13:04:35 UTC
Permalink
All,

I recently tried building Open MPI 2.0.1 with the new Community Edition of
PGI on macOS. My first mistake was I was configuring with a configure line
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed from
the macOS build. Okay, I can remove that and I configured with:

./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1 | & tee
configure.pgi-16.10.log

But, now, when I try to actually build, I get an error pretty quick inside
the make:

CC printf.lo
CC proc.lo
CC qsort.lo

PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include/event2/util.h:
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

This was done with -j2, so if I remake with 'make V=1' I see:

source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H -I.
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include/event2/util.h:
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I guess my question is whether this is an issue with PGI or Open MPI or
both? I'm not too sure. I've also asked about this on the PGI forums as
well (http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since
I'm not sure. But, no matter what, does anyone have thoughts on how to
solve this?

Thanks,
Matt
--
Matt Thompson
Jeff Hammond
2016-11-28 16:18:39 UTC
Permalink
The following is the code that fails. The comments indicate the likely
source of the error.

Please see
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f3afa2cd0eec05b0f4e54a60f50479
and other entries on https://www.google.com/search?q=pgi+stdint.h.

You may want to debug libevent by itself (
https://github.com/libevent/libevent).

I do not have PGI installed on my Mac, so I can't reproduce this.

Best,

Jeff

/**

* @name Standard integer types.

*

* * Integer type definitions for types that are supposed to be defined in
the*

* * C99-specified stdint.h. Shamefully, some platforms do not include*

* * stdint.h, so we need to replace it. (If you are on a platform like
this,*

* * your C headers are now over 10 years out of date. You should bug them
to*

* * do something about this.)*

*

* We define:

*

* <dl>

* <dt>ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t</dt>

* <dd>unsigned integer types of exactly 64, 32, 16, and 8 bits

* respectively.</dd>

* <dt>ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t</dt>

* <dd>signed integer types of exactly 64, 32, 16, and 8 bits

* respectively.</dd>

* <dt>ev_uintptr_t, ev_intptr_t</dt>

* <dd>unsigned/signed integers large enough

* to hold a pointer without loss of bits.</dd>

* <dt>ev_ssize_t</dt>

* <dd>A signed type of the same size as size_t</dd>

* <dt>ev_off_t</dt>

* <dd>A signed type typically used to represent offsets within a

* (potentially large) file</dd>

*

* @{

*/

#ifdef _EVENT_HAVE_UINT64_T

#define ev_uint64_t uint64_t

#define ev_int64_t int64_t

#elif defined(WIN32)

#define ev_uint64_t unsigned __int64

#define ev_int64_t signed __int64

#elif _EVENT_SIZEOF_LONG_LONG == 8

#define ev_uint64_t unsigned long long

#define ev_int64_t long long

#elif _EVENT_SIZEOF_LONG == 8

#define ev_uint64_t unsigned long

#define ev_int64_t long

#elif defined(_EVENT_IN_DOXYGEN)

#define ev_uint64_t ...

#define ev_int64_t ...

#else

#error "No way to define ev_uint64_t"

#endif
Post by Matt Thompson
All,
I recently tried building Open MPI 2.0.1 with the new Community Edition of
PGI on macOS. My first mistake was I was configuring with a configure line
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed from
./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1 | &
tee configure.pgi-16.10.log
But, now, when I try to actually build, I get an error pretty quick inside
CC printf.lo
CC proc.lo
CC qsort.lo
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
libevent2022/libevent/include/event2/util.h: 126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H -I.
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include -I../../opal/mca/hwloc/
hwloc1112/hwloc/include/private/autogen -I../../opal/mca/hwloc/
hwloc1112/hwloc/include/hwloc/autogen -I../../ompi/mpiext/cuda/c -I../..
-I../../orte/include -I/Users/mathomp4/src/MPI/
openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
libevent2022/libevent/include/event2/util.h: 126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I guess my question is whether this is an issue with PGI or Open MPI or
both? I'm not too sure. I've also asked about this on the PGI forums as
well (http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since
I'm not sure. But, no matter what, does anyone have thoughts on how to
solve this?
Thanks,
Matt
--
Matt Thompson
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
***@gmail.com
http://jeffhammond.github.io/
Bennet Fauber
2016-11-28 16:39:16 UTC
Permalink
I think PGI uses installed GCC components for some parts of standard C
(at least for some things on Linux, it does; and I imagine it is
similar for Mac). If you look at the post at

http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f3afa2cd0eec05b0f4e54a60f50479

The problem seems to have been one with the Xcode configuration:

"It turns out my Xcode was messed up as I was missing /usr/include/.
After rerunning xcode-select --install it works now."

On my OS X 10.11.6, I have /usr/include/stdint.h without having the
PGI compilers. This may be related to the GNU command line tools
installation...? I think that is now optional and may be needed.

Sorry for the noise if this is irrelevant.
Post by Jeff Hammond
The following is the code that fails. The comments indicate the likely
source of the error.
Please see
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f3afa2cd0eec05b0f4e54a60f50479
and other entries on https://www.google.com/search?q=pgi+stdint.h.
You may want to debug libevent by itself
(https://github.com/libevent/libevent).
I do not have PGI installed on my Mac, so I can't reproduce this.
Best,
Jeff
/**
*
* Integer type definitions for types that are supposed to be defined in the
* C99-specified stdint.h. Shamefully, some platforms do not include
* stdint.h, so we need to replace it. (If you are on a platform like this,
* your C headers are now over 10 years out of date. You should bug them to
* do something about this.)
*
*
* <dl>
* <dt>ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t</dt>
* <dd>unsigned integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t</dt>
* <dd>signed integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_uintptr_t, ev_intptr_t</dt>
* <dd>unsigned/signed integers large enough
* to hold a pointer without loss of bits.</dd>
* <dt>ev_ssize_t</dt>
* <dd>A signed type of the same size as size_t</dd>
* <dt>ev_off_t</dt>
* <dd>A signed type typically used to represent offsets within a
* (potentially large) file</dd>
*
*/
#ifdef _EVENT_HAVE_UINT64_T
#define ev_uint64_t uint64_t
#define ev_int64_t int64_t
#elif defined(WIN32)
#define ev_uint64_t unsigned __int64
#define ev_int64_t signed __int64
#elif _EVENT_SIZEOF_LONG_LONG == 8
#define ev_uint64_t unsigned long long
#define ev_int64_t long long
#elif _EVENT_SIZEOF_LONG == 8
#define ev_uint64_t unsigned long
#define ev_int64_t long
#elif defined(_EVENT_IN_DOXYGEN)
#define ev_uint64_t ...
#define ev_int64_t ...
#else
#error "No way to define ev_uint64_t"
#endif
Post by Matt Thompson
All,
I recently tried building Open MPI 2.0.1 with the new Community Edition of
PGI on macOS. My first mistake was I was configuring with a configure line
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed from the
./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1 | & tee
configure.pgi-16.10.log
But, now, when I try to actually build, I get an error pretty quick inside
CC printf.lo
CC proc.lo
CC qsort.lo
PGC-F-0249-#error -- "No way to define ev_uint64_t"
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H -I.
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I guess my question is whether this is an issue with PGI or Open MPI or
both? I'm not too sure. I've also asked about this on the PGI forums as well
(http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since I'm not
sure. But, no matter what, does anyone have thoughts on how to solve this?
Thanks,
Matt
--
Matt Thompson
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
Matt Thompson
2016-11-28 17:49:21 UTC
Permalink
Hmm. Well, I definitely have /usr/include/stdint.h as I previously was
trying work with clang as compiler stack. And as near as I can tell, Open
MPI's configure is seeing /usr/include as oldincludedir, but maybe that's
not how it finds it?

If I check my configure output:

============================================================================
== Configuring Open MPI
============================================================================

*** Startup tests
checking build system type... x86_64-apple-darwin15.6.0
<snip>
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes

So, the startup saw it. But:

--- MCA component event:libevent2022 (m4 configuration macro, priority 80)
checking for MCA component event:libevent2022 compile mode... static
checking libevent configuration args... --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --d
isable-evport
configure: OPAL configuring in opal/mca/event/libevent2022/libevent
configure: running /bin/sh './configure' --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --
disable-evport '--disable-wrapper-rpath' 'CC=pgcc' 'CXX=pgc++'
'FC=pgfortran' 'CFLAGS=-m64' 'CXXFLAGS=-m64' 'FCFLAGS=-m64' '--w
ithout-verbs'
'--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1'
'CPPFLAGS=-I/Users/mathomp4/src/MPI/openmpi-
2.0.1 -I/Users/mathomp4/src/MPI/openmpi-2.0.1
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/include
-I/Users/mathomp4/src/MPI/o
penmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include -Drandom=opal_random'
--cache-file=/dev/null --srcdir=. --disable-option-che
cking
checking for a BSD-compatible install... /usr/bin/install -c
<snip>
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no

So, it's like whatever magic found stdint.h for the startup isn't passed
down to libevent when it builds? As I scan the configure output, PMIx sees
stdint.h in its section and ROMIO sees it as well, but not libevent2022.
The Makefiles inside of libevent2022 do have 'oldincludedir =
/usr/include'. Hmm.
Post by Bennet Fauber
I think PGI uses installed GCC components for some parts of standard C
(at least for some things on Linux, it does; and I imagine it is
similar for Mac). If you look at the post at
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=
17f3afa2cd0eec05b0f4e54a60f50479
"It turns out my Xcode was messed up as I was missing /usr/include/.
After rerunning xcode-select --install it works now."
On my OS X 10.11.6, I have /usr/include/stdint.h without having the
PGI compilers. This may be related to the GNU command line tools
installation...? I think that is now optional and may be needed.
Sorry for the noise if this is irrelevant.
Post by Jeff Hammond
The following is the code that fails. The comments indicate the likely
source of the error.
Please see
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=
17f3afa2cd0eec05b0f4e54a60f50479
Post by Jeff Hammond
and other entries on https://www.google.com/search?q=pgi+stdint.h.
You may want to debug libevent by itself
(https://github.com/libevent/libevent).
I do not have PGI installed on my Mac, so I can't reproduce this.
Best,
Jeff
/**
*
* Integer type definitions for types that are supposed to be defined in
the
Post by Jeff Hammond
* C99-specified stdint.h. Shamefully, some platforms do not include
* stdint.h, so we need to replace it. (If you are on a platform like
this,
Post by Jeff Hammond
* your C headers are now over 10 years out of date. You should bug
them to
Post by Jeff Hammond
* do something about this.)
*
*
* <dl>
* <dt>ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t</dt>
* <dd>unsigned integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t</dt>
* <dd>signed integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_uintptr_t, ev_intptr_t</dt>
* <dd>unsigned/signed integers large enough
* to hold a pointer without loss of bits.</dd>
* <dt>ev_ssize_t</dt>
* <dd>A signed type of the same size as size_t</dd>
* <dt>ev_off_t</dt>
* <dd>A signed type typically used to represent offsets within a
* (potentially large) file</dd>
*
*/
#ifdef _EVENT_HAVE_UINT64_T
#define ev_uint64_t uint64_t
#define ev_int64_t int64_t
#elif defined(WIN32)
#define ev_uint64_t unsigned __int64
#define ev_int64_t signed __int64
#elif _EVENT_SIZEOF_LONG_LONG == 8
#define ev_uint64_t unsigned long long
#define ev_int64_t long long
#elif _EVENT_SIZEOF_LONG == 8
#define ev_uint64_t unsigned long
#define ev_int64_t long
#elif defined(_EVENT_IN_DOXYGEN)
#define ev_uint64_t ...
#define ev_int64_t ...
#else
#error "No way to define ev_uint64_t"
#endif
Post by Matt Thompson
All,
I recently tried building Open MPI 2.0.1 with the new Community Edition
of
Post by Jeff Hammond
Post by Matt Thompson
PGI on macOS. My first mistake was I was configuring with a configure
line
Post by Jeff Hammond
Post by Matt Thompson
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed
from the
Post by Jeff Hammond
Post by Matt Thompson
./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1 |
& tee
Post by Jeff Hammond
Post by Matt Thompson
configure.pgi-16.10.log
But, now, when I try to actually build, I get an error pretty quick
inside
Post by Jeff Hammond
Post by Matt Thompson
CC printf.lo
CC proc.lo
CC qsort.lo
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H
-I.
Post by Jeff Hammond
Post by Matt Thompson
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/
hwloc1112/hwloc/include
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
libevent2022/libevent
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
libevent2022/libevent/include
Post by Jeff Hammond
Post by Matt Thompson
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/
hwloc1112/hwloc/include
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
libevent2022/libevent
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
libevent2022/libevent/include
Post by Jeff Hammond
Post by Matt Thompson
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I guess my question is whether this is an issue with PGI or Open MPI or
both? I'm not too sure. I've also asked about this on the PGI forums as
well
Post by Jeff Hammond
Post by Matt Thompson
(http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since
I'm not
Post by Jeff Hammond
Post by Matt Thompson
sure. But, no matter what, does anyone have thoughts on how to solve
this?
Post by Jeff Hammond
Post by Matt Thompson
Thanks,
Matt
--
Matt Thompson
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Matt Thompson

Man Among Men
Fulcrum of History
Bennet Fauber
2016-11-28 18:02:42 UTC
Permalink
This post might be inappropriate. Click to display it.
Jeff Hammond
2016-11-28 20:11:00 UTC
Permalink
attached config.log that contains the details of the following failures is
the best way to make forward-progress here. that none of the system
headers are detected suggests a rather serious compiler problem that may
not have anything to do with headers.

checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
Post by Matt Thompson
Hmm. Well, I definitely have /usr/include/stdint.h as I previously was
trying work with clang as compiler stack. And as near as I can tell, Open
MPI's configure is seeing /usr/include as oldincludedir, but maybe that's
not how it finds it?
============================================================
================
== Configuring Open MPI
============================================================
================
*** Startup tests
checking build system type... x86_64-apple-darwin15.6.0
<snip>
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
--- MCA component event:libevent2022 (m4 configuration macro, priority 80)
checking for MCA component event:libevent2022 compile mode... static
checking libevent configuration args... --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --d
isable-evport
configure: OPAL configuring in opal/mca/event/libevent2022/libevent
configure: running /bin/sh './configure' --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --
disable-evport '--disable-wrapper-rpath' 'CC=pgcc' 'CXX=pgc++'
'FC=pgfortran' 'CFLAGS=-m64' 'CXXFLAGS=-m64' 'FCFLAGS=-m64' '--w
ithout-verbs' '--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1'
'CPPFLAGS=-I/Users/mathomp4/src/MPI/openmpi-
2.0.1 -I/Users/mathomp4/src/MPI/openmpi-2.0.1 -I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/include
-I/Users/mathomp4/src/MPI/o
penmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include -Drandom=opal_random'
--cache-file=/dev/null --srcdir=. --disable-option-che
cking
checking for a BSD-compatible install... /usr/bin/install -c
<snip>
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
So, it's like whatever magic found stdint.h for the startup isn't passed
down to libevent when it builds? As I scan the configure output, PMIx sees
stdint.h in its section and ROMIO sees it as well, but not libevent2022.
The Makefiles inside of libevent2022 do have 'oldincludedir =
/usr/include'. Hmm.
Post by Bennet Fauber
I think PGI uses installed GCC components for some parts of standard C
(at least for some things on Linux, it does; and I imagine it is
similar for Mac). If you look at the post at
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f
3afa2cd0eec05b0f4e54a60f50479
"It turns out my Xcode was messed up as I was missing /usr/include/.
After rerunning xcode-select --install it works now."
On my OS X 10.11.6, I have /usr/include/stdint.h without having the
PGI compilers. This may be related to the GNU command line tools
installation...? I think that is now optional and may be needed.
Sorry for the noise if this is irrelevant.
Post by Jeff Hammond
The following is the code that fails. The comments indicate the likely
source of the error.
Please see
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f
3afa2cd0eec05b0f4e54a60f50479
Post by Jeff Hammond
and other entries on https://www.google.com/search?q=pgi+stdint.h.
You may want to debug libevent by itself
(https://github.com/libevent/libevent).
I do not have PGI installed on my Mac, so I can't reproduce this.
Best,
Jeff
/**
*
* Integer type definitions for types that are supposed to be defined
in the
Post by Jeff Hammond
* C99-specified stdint.h. Shamefully, some platforms do not include
* stdint.h, so we need to replace it. (If you are on a platform like
this,
Post by Jeff Hammond
* your C headers are now over 10 years out of date. You should bug
them to
Post by Jeff Hammond
* do something about this.)
*
*
* <dl>
* <dt>ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t</dt>
* <dd>unsigned integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t</dt>
* <dd>signed integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_uintptr_t, ev_intptr_t</dt>
* <dd>unsigned/signed integers large enough
* to hold a pointer without loss of bits.</dd>
* <dt>ev_ssize_t</dt>
* <dd>A signed type of the same size as size_t</dd>
* <dt>ev_off_t</dt>
* <dd>A signed type typically used to represent offsets within a
* (potentially large) file</dd>
*
*/
#ifdef _EVENT_HAVE_UINT64_T
#define ev_uint64_t uint64_t
#define ev_int64_t int64_t
#elif defined(WIN32)
#define ev_uint64_t unsigned __int64
#define ev_int64_t signed __int64
#elif _EVENT_SIZEOF_LONG_LONG == 8
#define ev_uint64_t unsigned long long
#define ev_int64_t long long
#elif _EVENT_SIZEOF_LONG == 8
#define ev_uint64_t unsigned long
#define ev_int64_t long
#elif defined(_EVENT_IN_DOXYGEN)
#define ev_uint64_t ...
#define ev_int64_t ...
#else
#error "No way to define ev_uint64_t"
#endif
Post by Matt Thompson
All,
I recently tried building Open MPI 2.0.1 with the new Community
Edition of
Post by Jeff Hammond
Post by Matt Thompson
PGI on macOS. My first mistake was I was configuring with a configure
line
Post by Jeff Hammond
Post by Matt Thompson
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed
from the
Post by Jeff Hammond
Post by Matt Thompson
./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1 |
& tee
Post by Jeff Hammond
Post by Matt Thompson
configure.pgi-16.10.log
But, now, when I try to actually build, I get an error pretty quick
inside
Post by Jeff Hammond
Post by Matt Thompson
CC printf.lo
CC proc.lo
CC qsort.lo
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libeve
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H
-I.
Post by Jeff Hammond
Post by Matt Thompson
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc
1112/hwloc/include
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent/include
Post by Jeff Hammond
Post by Matt Thompson
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc
1112/hwloc/include
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent/include
Post by Jeff Hammond
Post by Matt Thompson
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libeve
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I guess my question is whether this is an issue with PGI or Open MPI or
both? I'm not too sure. I've also asked about this on the PGI forums
as well
Post by Jeff Hammond
Post by Matt Thompson
(http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since
I'm not
Post by Jeff Hammond
Post by Matt Thompson
sure. But, no matter what, does anyone have thoughts on how to solve
this?
Post by Jeff Hammond
Post by Matt Thompson
Thanks,
Matt
--
Matt Thompson
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Matt Thompson
Man Among Men
Fulcrum of History
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
***@gmail.com
http://jeffhammond.github.io/
Bennet Fauber
2016-11-29 16:10:52 UTC
Permalink
Note that Matt was quite correct, things seem to go fine with the
configure tests up until it gets to the libevent portion.

I include what appears to be the first major error block from
config.log below. The first error is triggered by this:

/* This SDK is designed to work with clang and specific versions of
* gcc >= 4.0 with Apple's patch sets */
#if !defined(__GNUC__) || __GNUC__ < 4
#warning "Unsupported compiler detected"
#endif

If I copy the header and source file out and try to compile with my
command line gcc, I get this.

[***@bennet opt]$ gcc --version
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[***@bennet opt]$ gcc -c -O -DNDEBUG -I/usr/include conftest.c
conftest.c:37:13: error: use of undeclared identifier 'int8_t'
if (sizeof (int8_t))
^
1 error generated.



configure:15305: checking for int8_t
configure:15305: pgcc -c -O -DNDEBUG -I/usr/include conftest.c >&5
PGC-W-0267-#warning -- "Unsupported compiler detected"
(/usr/include/sys/cdefs.h: 81)
PGC-S-0040-Illegal use of symbol, uint16_t
(/usr/include/libkern/_OSByteOrder.h: 96)
PGC-W-0156-Type not specified, 'int' assumed
(/usr/include/libkern/_OSByteOrder.h: 96)
PGC-S-0040-Illegal use of symbol, uint16_t
(/usr/include/libkern/_OSByteOrder.h: 97)
PGC-W-0156-Type not specified, 'int' assumed
(/usr/include/libkern/_OSByteOrder.h: 97)
PGC-S-0040-Illegal use of symbol, uint32_t
(/usr/include/libkern/_OSByteOrder.h: 105)
PGC-W-0156-Type not specified, 'int' assumed
(/usr/include/libkern/_OSByteOrder.h: 105)
PGC-S-0040-Illegal use of symbol, uint32_t
(/usr/include/libkern/_OSByteOrder.h: 106)
PGC-W-0156-Type not specified, 'int' assumed
(/usr/include/libkern/_OSByteOrder.h: 106)
PGC-S-0040-Illegal use of symbol, uint64_t
(/usr/include/libkern/_OSByteOrder.h: 114)
PGC-W-0156-Type not specified, 'int' assumed
(/usr/include/libkern/_OSByteOrder.h: 114)
PGC-S-0040-Illegal use of symbol, uint64_t
(/usr/include/libkern/_OSByteOrder.h: 115)
PGC-W-0156-Type not specified, 'int' assumed
(/usr/include/libkern/_OSByteOrder.h: 115)
PGC-S-0043-Redefinition of symbol, uint16_t
(/usr/include/_types/_uint16_t.h: 31)
PGC-S-0043-Redefinition of symbol, uint32_t
(/usr/include/_types/_uint32_t.h: 31)
PGC-S-0043-Redefinition of symbol, uint64_t
(/usr/include/_types/_uint64_t.h: 31)
PGC/x86-64 OSX 16.10-0: compilation completed with severe errors
configure:15305: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Open MPI"
| #define PACKAGE_TARNAME "openmpi"
| #define PACKAGE_VERSION "2.0.1"
| #define PACKAGE_STRING "Open MPI 2.0.1"
| #define PACKAGE_BUGREPORT "http://www.open-mpi.org/community/help/"
| #define PACKAGE_URL ""
| #define OPAL_ARCH "x86_64-apple-darwin15.6.0"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define OMPI_MAJOR_VERSION 2
| #define OMPI_MINOR_VERSION 0
| #define OMPI_RELEASE_VERSION 1
| #define OMPI_GREEK_VERSION ""
| #define OMPI_REPO_REV "v2.0.0-257-gee86e07"
| #define OMPI_TARBALL_VERSION "2.0.1"
| #define OMPI_VERSION "1"
| #define OMPI_RELEASE_DATE "Sep 02, 2016"
| #define ORTE_MAJOR_VERSION 2
| #define ORTE_MINOR_VERSION 0
| #define ORTE_RELEASE_VERSION 1
| #define ORTE_GREEK_VERSION ""
| #define ORTE_REPO_REV "v2.0.0-257-gee86e07"
| #define ORTE_TARBALL_VERSION "2.0.1"
| #define ORTE_VERSION "1"
| #define ORTE_RELEASE_DATE "Sep 02, 2016"
| #define OSHMEM_MAJOR_VERSION 2
| #define OSHMEM_MINOR_VERSION 0
| #define OSHMEM_RELEASE_VERSION 1
| #define OSHMEM_GREEK_VERSION ""
| #define OSHMEM_REPO_REV "v2.0.0-257-gee86e07"
| #define OSHMEM_TARBALL_VERSION "2.0.1"
| #define OSHMEM_VERSION "1"
| #define OSHMEM_RELEASE_DATE "Sep 02, 2016"
| #define OPAL_MAJOR_VERSION 2
| #define OPAL_MINOR_VERSION 0
| #define OPAL_RELEASE_VERSION 1
| #define OPAL_GREEK_VERSION ""
| #define OPAL_REPO_REV "v2.0.0-257-gee86e07"
| #define OPAL_TARBALL_VERSION "2.0.1"
| #define OPAL_VERSION "1"
| #define OPAL_RELEASE_DATE "Sep 02, 2016"
| #define OPAL_ENABLE_MEM_DEBUG 0
| #define OPAL_ENABLE_MEM_PROFILE 0
| #define OPAL_ENABLE_TIMING 0
| #define OPAL_ENABLE_DEBUG 0
| #define OPAL_WANT_PRETTY_PRINT_STACKTRACE 1
| #define OPAL_ENABLE_PTY_SUPPORT 1
| #define OPAL_ENABLE_DLOPEN_SUPPORT 1
| #define OPAL_ENABLE_HETEROGENEOUS_SUPPORT 0
| #define OPAL_ALIGN_WORD_SIZE_INTEGERS 0
| #define OPAL_WANT_HOME_CONFIG_FILES 1
| #define OPAL_ENABLE_IPV6 0
| #define OPAL_PACKAGE_STRING "Open MPI ***@stentorian.local Distribution"
| #define OPAL_IDENT_STRING "2.0.1"
| #define OPAL_MAX_PROCESSOR_NAME 256
| #define OPAL_MAX_ERROR_STRING 256
| #define OPAL_MAX_OBJECT_NAME 64
| #define OPAL_MAX_INFO_KEY 36
| #define OPAL_MAX_INFO_VAL 256
| #define OPAL_MAX_PORT_NAME 1024
| #define OPAL_MAX_DATAREP_STRING 128
| #define OPAL_ENABLE_CRDEBUG 0
| #define OPAL_ENABLE_GETPWUID 1
| #define OPAL_ENABLE_PROGRESS_THREADS 0
| #define OPAL_HAVE_SOLARIS 0
| #define OPAL_CUDA_SUPPORT 0
| #define OPAL_CUDA_SYNC_MEMOPS 0
| #define OPAL_CUDA_GET_ATTRIBUTES 0
| #define OPAL_CUDA_GDR_SUPPORT 0
| #define ORTE_WANT_ORTERUN_PREFIX_BY_DEFAULT 0
| #define ORTE_ENABLE_STATIC_PORTS 1
| #define OMPI_WANT_MPI_INTERFACE_WARNING 1
| #define OMPI_GROUP_SPARSE 0
| #define OMPI_WANT_PERUSE 0
| #define OMPI_WANT_MPI_CXX_SEEK 1
| #define MPI_PARAM_CHECK ompi_mpi_param_check
| #define OMPI_PARAM_CHECK 1
| #define OMPI_BUILD_FORTRAN_F08_SUBARRAYS 0
| #define OSHMEM_SPEC_COMPAT 0
| #define OSHMEM_PARAM_CHECK 0
| #define OPAL_CC "pgcc"
| #define STDC_HEADERS 1
| #define _GNU_SOURCE 1
| #define OPAL_C_HAVE_BUILTIN_EXPECT 1
| #define OPAL_C_HAVE_BUILTIN_PREFETCH 0
| #define OPAL_C_HAVE_BUILTIN_CLZ 0
| #define OPAL_CC_USE_PRAGMA_IDENT 0
| #define OPAL_CC_USE_IDENT 0
| #define OPAL_CC_USE_PRAGMA_COMMENT
| #define OPAL_CC_USE_CONST_CHAR_IDENT 1
| /* end confdefs.h. */
| #include <stdio.h>
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # ifdef HAVE_STDLIB_H
| # include <stdlib.h>
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| # include <memory.h>
| # endif
| # include <string.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| int
| main ()
| {
| if (sizeof (int8_t))
| return 0;
| ;
| return 0;
| }
configure:15305: result: no
Post by Jeff Hammond
attached config.log that contains the details of the following failures is
the best way to make forward-progress here. that none of the system headers
are detected suggests a rather serious compiler problem that may not have
anything to do with headers.
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
Post by Matt Thompson
Hmm. Well, I definitely have /usr/include/stdint.h as I previously was
trying work with clang as compiler stack. And as near as I can tell, Open
MPI's configure is seeing /usr/include as oldincludedir, but maybe that's
not how it finds it?
============================================================================
== Configuring Open MPI
============================================================================
*** Startup tests
checking build system type... x86_64-apple-darwin15.6.0
<snip>
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
--- MCA component event:libevent2022 (m4 configuration macro, priority 80)
checking for MCA component event:libevent2022 compile mode... static
checking libevent configuration args... --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --d
isable-evport
configure: OPAL configuring in opal/mca/event/libevent2022/libevent
configure: running /bin/sh './configure' --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --
disable-evport '--disable-wrapper-rpath' 'CC=pgcc' 'CXX=pgc++'
'FC=pgfortran' 'CFLAGS=-m64' 'CXXFLAGS=-m64' 'FCFLAGS=-m64' '--w
ithout-verbs'
'--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1'
'CPPFLAGS=-I/Users/mathomp4/src/MPI/openmpi-
2.0.1 -I/Users/mathomp4/src/MPI/openmpi-2.0.1
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/include
-I/Users/mathomp4/src/MPI/o
penmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include -Drandom=opal_random'
--cache-file=/dev/null --srcdir=. --disable-option-che
cking
checking for a BSD-compatible install... /usr/bin/install -c
<snip>
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
So, it's like whatever magic found stdint.h for the startup isn't passed
down to libevent when it builds? As I scan the configure output, PMIx sees
stdint.h in its section and ROMIO sees it as well, but not libevent2022. The
Makefiles inside of libevent2022 do have 'oldincludedir = /usr/include'.
Hmm.
Post by Bennet Fauber
I think PGI uses installed GCC components for some parts of standard C
(at least for some things on Linux, it does; and I imagine it is
similar for Mac). If you look at the post at
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f3afa2cd0eec05b0f4e54a60f50479
"It turns out my Xcode was messed up as I was missing /usr/include/.
After rerunning xcode-select --install it works now."
On my OS X 10.11.6, I have /usr/include/stdint.h without having the
PGI compilers. This may be related to the GNU command line tools
installation...? I think that is now optional and may be needed.
Sorry for the noise if this is irrelevant.
Post by Jeff Hammond
The following is the code that fails. The comments indicate the likely
source of the error.
Please see
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f3afa2cd0eec05b0f4e54a60f50479
and other entries on https://www.google.com/search?q=pgi+stdint.h.
You may want to debug libevent by itself
(https://github.com/libevent/libevent).
I do not have PGI installed on my Mac, so I can't reproduce this.
Best,
Jeff
/**
*
* Integer type definitions for types that are supposed to be defined in the
* C99-specified stdint.h. Shamefully, some platforms do not include
* stdint.h, so we need to replace it. (If you are on a platform like this,
* your C headers are now over 10 years out of date. You should bug them to
* do something about this.)
*
*
* <dl>
* <dt>ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t</dt>
* <dd>unsigned integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t</dt>
* <dd>signed integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_uintptr_t, ev_intptr_t</dt>
* <dd>unsigned/signed integers large enough
* to hold a pointer without loss of bits.</dd>
* <dt>ev_ssize_t</dt>
* <dd>A signed type of the same size as size_t</dd>
* <dt>ev_off_t</dt>
* <dd>A signed type typically used to represent offsets within a
* (potentially large) file</dd>
*
*/
#ifdef _EVENT_HAVE_UINT64_T
#define ev_uint64_t uint64_t
#define ev_int64_t int64_t
#elif defined(WIN32)
#define ev_uint64_t unsigned __int64
#define ev_int64_t signed __int64
#elif _EVENT_SIZEOF_LONG_LONG == 8
#define ev_uint64_t unsigned long long
#define ev_int64_t long long
#elif _EVENT_SIZEOF_LONG == 8
#define ev_uint64_t unsigned long
#define ev_int64_t long
#elif defined(_EVENT_IN_DOXYGEN)
#define ev_uint64_t ...
#define ev_int64_t ...
#else
#error "No way to define ev_uint64_t"
#endif
Post by Matt Thompson
All,
I recently tried building Open MPI 2.0.1 with the new Community Edition of
PGI on macOS. My first mistake was I was configuring with a configure line
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed from the
./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1 | & tee
configure.pgi-16.10.log
But, now, when I try to actually build, I get an error pretty quick inside
CC printf.lo
CC proc.lo
CC qsort.lo
PGC-F-0249-#error -- "No way to define ev_uint64_t"
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H -I.
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libevent2022/libevent/include
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I guess my question is whether this is an issue with PGI or Open MPI or
both? I'm not too sure. I've also asked about this on the PGI forums as well
(http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since I'm not
sure. But, no matter what, does anyone have thoughts on how to solve this?
Thanks,
Matt
--
Matt Thompson
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Matt Thompson
Man Among Men
Fulcrum of History
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
Matt Thompson
2016-11-30 20:18:39 UTC
Permalink
Well, jtull over at PGI seemed to have the "magic sauce":

http://www.pgroup.com/userforum/viewtopic.php?p=21105#21105

Namely, I think it's the siterc file. I'm not sure which of the adaptations
fixes the issue yet, though.
Post by Jeff Hammond
attached config.log that contains the details of the following failures is
the best way to make forward-progress here. that none of the system
headers are detected suggests a rather serious compiler problem that may
not have anything to do with headers.
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
Post by Matt Thompson
Hmm. Well, I definitely have /usr/include/stdint.h as I previously was
trying work with clang as compiler stack. And as near as I can tell, Open
MPI's configure is seeing /usr/include as oldincludedir, but maybe that's
not how it finds it?
============================================================
================
== Configuring Open MPI
============================================================
================
*** Startup tests
checking build system type... x86_64-apple-darwin15.6.0
<snip>
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
--- MCA component event:libevent2022 (m4 configuration macro, priority 80)
checking for MCA component event:libevent2022 compile mode... static
checking libevent configuration args... --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --d
isable-evport
configure: OPAL configuring in opal/mca/event/libevent2022/libevent
configure: running /bin/sh './configure' --disable-dns --disable-http
--disable-rpc --disable-openssl --enable-thread-support --
disable-evport '--disable-wrapper-rpath' 'CC=pgcc' 'CXX=pgc++'
'FC=pgfortran' 'CFLAGS=-m64' 'CXXFLAGS=-m64' 'FCFLAGS=-m64' '--w
ithout-verbs' '--prefix=/Users/mathomp4/inst
alled/Compiler/pgi-16.10/openmpi/2.0.1' 'CPPFLAGS=-I/Users/mathomp4/sr
c/MPI/openmpi-
2.0.1 -I/Users/mathomp4/src/MPI/openmpi-2.0.1
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/include
-I/Users/mathomp4/src/MPI/o
penmpi-2.0.1/opal/mca/hwloc/hwloc1112/hwloc/include
-Drandom=opal_random' --cache-file=/dev/null --srcdir=. --disable-option-che
cking
checking for a BSD-compatible install... /usr/bin/install -c
<snip>
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
So, it's like whatever magic found stdint.h for the startup isn't passed
down to libevent when it builds? As I scan the configure output, PMIx sees
stdint.h in its section and ROMIO sees it as well, but not libevent2022.
The Makefiles inside of libevent2022 do have 'oldincludedir =
/usr/include'. Hmm.
Post by Bennet Fauber
I think PGI uses installed GCC components for some parts of standard C
(at least for some things on Linux, it does; and I imagine it is
similar for Mac). If you look at the post at
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f
3afa2cd0eec05b0f4e54a60f50479
"It turns out my Xcode was messed up as I was missing /usr/include/.
After rerunning xcode-select --install it works now."
On my OS X 10.11.6, I have /usr/include/stdint.h without having the
PGI compilers. This may be related to the GNU command line tools
installation...? I think that is now optional and may be needed.
Sorry for the noise if this is irrelevant.
Post by Jeff Hammond
The following is the code that fails. The comments indicate the likely
source of the error.
Please see
http://www.pgroup.com/userforum/viewtopic.php?t=5147&sid=17f
3afa2cd0eec05b0f4e54a60f50479
Post by Jeff Hammond
and other entries on https://www.google.com/search?q=pgi+stdint.h.
You may want to debug libevent by itself
(https://github.com/libevent/libevent).
I do not have PGI installed on my Mac, so I can't reproduce this.
Best,
Jeff
/**
*
* Integer type definitions for types that are supposed to be defined
in the
Post by Jeff Hammond
* C99-specified stdint.h. Shamefully, some platforms do not include
* stdint.h, so we need to replace it. (If you are on a platform like
this,
Post by Jeff Hammond
* your C headers are now over 10 years out of date. You should bug
them to
Post by Jeff Hammond
* do something about this.)
*
*
* <dl>
* <dt>ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t</dt>
* <dd>unsigned integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t</dt>
* <dd>signed integer types of exactly 64, 32, 16, and 8 bits
* respectively.</dd>
* <dt>ev_uintptr_t, ev_intptr_t</dt>
* <dd>unsigned/signed integers large enough
* to hold a pointer without loss of bits.</dd>
* <dt>ev_ssize_t</dt>
* <dd>A signed type of the same size as size_t</dd>
* <dt>ev_off_t</dt>
* <dd>A signed type typically used to represent offsets within a
* (potentially large) file</dd>
*
*/
#ifdef _EVENT_HAVE_UINT64_T
#define ev_uint64_t uint64_t
#define ev_int64_t int64_t
#elif defined(WIN32)
#define ev_uint64_t unsigned __int64
#define ev_int64_t signed __int64
#elif _EVENT_SIZEOF_LONG_LONG == 8
#define ev_uint64_t unsigned long long
#define ev_int64_t long long
#elif _EVENT_SIZEOF_LONG == 8
#define ev_uint64_t unsigned long
#define ev_int64_t long
#elif defined(_EVENT_IN_DOXYGEN)
#define ev_uint64_t ...
#define ev_int64_t ...
#else
#error "No way to define ev_uint64_t"
#endif
Post by Matt Thompson
All,
I recently tried building Open MPI 2.0.1 with the new Community
Edition of
Post by Jeff Hammond
Post by Matt Thompson
PGI on macOS. My first mistake was I was configuring with a configure
line
Post by Jeff Hammond
Post by Matt Thompson
I'd cribbed from Linux that had -fPIC. Apparently -fPIC was removed
from the
Post by Jeff Hammond
Post by Matt Thompson
./configure --disable-wrapper-rpath CC=pgcc CXX=pgc++ FC=pgfortran
CFLAGS='-m64' CXXFLAGS='-m64' FCFLAGS='-m64' --without-verbs
--prefix=/Users/mathomp4/installed/Compiler/pgi-16.10/openmpi/2.0.1
| & tee
Post by Jeff Hammond
Post by Matt Thompson
configure.pgi-16.10.log
But, now, when I try to actually build, I get an error pretty quick
inside
Post by Jeff Hammond
Post by Matt Thompson
CC printf.lo
CC proc.lo
CC qsort.lo
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libeve
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
CC show_help.lo
make[3]: *** [proc.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
source='proc.c' object='proc.lo' libtool=yes \
DEPDIR=.deps depmode=pgcc /bin/sh ../../config/depcomp \
/bin/sh ../../libtool --tag=CC --mode=compile pgcc -DHAVE_CONFIG_H
-I.
Post by Jeff Hammond
Post by Matt Thompson
-I../../opal/include -I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc
1112/hwloc/include
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent/include
Post by Jeff Hammond
Post by Matt Thompson
-O -DNDEBUG -m64 -c -o proc.lo proc.c
libtool: compile: pgcc -DHAVE_CONFIG_H -I. -I../../opal/include
-I../../ompi/include -I../../oshmem/include
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/private/autogen
-I../../opal/mca/hwloc/hwloc1112/hwloc/include/hwloc/autogen
-I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/hwloc/hwloc
1112/hwloc/include
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent
Post by Jeff Hammond
Post by Matt Thompson
-I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev
ent2022/libevent/include
Post by Jeff Hammond
Post by Matt Thompson
-O -DNDEBUG -m64 -c proc.c -MD -o proc.o
PGC-F-0249-#error -- "No way to define ev_uint64_t"
(/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libeve
126)
PGC/x86-64 OSX 16.10-0: compilation aborted
make[3]: *** [proc.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I guess my question is whether this is an issue with PGI or Open MPI
or
Post by Jeff Hammond
Post by Matt Thompson
both? I'm not too sure. I've also asked about this on the PGI forums
as well
Post by Jeff Hammond
Post by Matt Thompson
(http://www.pgroup.com/userforum/viewtopic.php?t=5413&start=0) since
I'm not
Post by Jeff Hammond
Post by Matt Thompson
sure. But, no matter what, does anyone have thoughts on how to solve
this?
Post by Jeff Hammond
Post by Matt Thompson
Thanks,
Matt
--
Matt Thompson
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Matt Thompson
Man Among Men
Fulcrum of History
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Jeff Hammond
http://jeffhammond.github.io/
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
--
Matt Thompson

Man Among Men
Fulcrum of History
Loading...