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