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. On Mon, Nov 28, 2016 at 3:11 PM, Jeff Hammond <jeff.scie...@gmail.com> wrote: > 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 > > > On Mon, Nov 28, 2016 at 9:49 AM, Matt Thompson <fort...@gmail.com> wrote: > >> 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/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. >> >> >> >> On Mon, Nov 28, 2016 at 11:39 AM, Bennet Fauber <ben...@umich.edu> wrote: >> >>> 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 >>> >>> 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. >>> >>> >>> >>> On Mon, Nov 28, 2016 at 11:18 AM, Jeff Hammond <jeff.scie...@gmail.com> >>> wrote: >>> > 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 >>> > 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 >>> > >>> > >>> > On Mon, Nov 28, 2016 at 5:04 AM, Matt Thompson <fort...@gmail.com> >>> wrote: >>> >> >>> >> 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/libeve >>> nt2022/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/hwloc >>> 1112/hwloc/include >>> >> -I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev >>> ent2022/libevent >>> >> -I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev >>> ent2022/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/hwloc >>> 1112/hwloc/include >>> >> -I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev >>> ent2022/libevent >>> >> -I/Users/mathomp4/src/MPI/openmpi-2.0.1/opal/mca/event/libev >>> ent2022/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/libeve >>> nt2022/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 >>> >> users@lists.open-mpi.org >>> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/users >>> > >>> > >>> > >>> > >>> > -- >>> > Jeff Hammond >>> > jeff.scie...@gmail.com >>> > http://jeffhammond.github.io/ >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> >> -- >> Matt Thompson >> >> Man Among Men >> Fulcrum of History >> >> >> _______________________________________________ >> users mailing list >> users@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/users >> > > > > -- > Jeff Hammond > jeff.scie...@gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > users mailing list > users@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/users > -- Matt Thompson Man Among Men Fulcrum of History
_______________________________________________ users mailing list users@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/users
