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