subject:"\[OMPI users\] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS"

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-30 Thread Matt Thompson

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 
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  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
>> 
>> 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
>> 
>> 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  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=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 
>>> 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=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

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-29 Thread Bennet Fauber

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.

[stentorian@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

[stentorian@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 bennet@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

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-28 Thread 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


On Mon, Nov 28, 2016 at 9:49 AM, Matt Thompson  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
> 
> 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
> 
> 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  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=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 
>> 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=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

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-28 Thread Bennet Fauber

You could try an explicit

$ export CFLAGS="-I/usr/include"

prior to running ./configure and see if that has any effect.

If it still throws the error, you can examine the full compile line
that make prints when it tries to compile the source file to see
whether the explicit include made it.  If it didn't, then perhaps the
problem is in the Makefile for that component?

As a hack, you could test by creating a symlink to stdint.h in a
directory that is in those printed and see if that gets you to the
next error.  That would remove the possibility that the problem is
that stdint.h is really missing and not the wrong one...?

Good luck!



On Mon, Nov 28, 2016 at 12:49 PM, Matt Thompson  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
> 
> 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
> 
> 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  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=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 
>> 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=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

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-28 Thread 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?

If I check my configure output:


== Configuring Open MPI


*** Startup tests
checking build system type... x86_64-apple-darwin15.6.0

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

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  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=
> 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 
> 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=
> 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:
> >
> >  *
> >
> >  * 
> >
> >  *   ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t
> >
> >  *  unsigned integer types of exactly 64, 32, 16, and 8 bits
> >
> >  *  respectively.
> >
> >  *ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t
> >
> >  *  signed integer types of exactly 64, 32, 16, and 8 bits
> >
> >  *  respectively.
> >
> >  *ev_uintptr_t, ev_intptr_t
> >
> >  *  unsigned/signed integers large enough
> >
> >  *  to hold a pointer without loss of bits.
> >
> >  *ev_ssize_t
> >
> >  *  A signed type of the same size as size_t
> >
> >  *ev_off_t
> >
> >  *  A signed type typically used to represent offsets

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-28 Thread 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=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  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=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:
>
>  *
>
>  * 
>
>  *   ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t
>
>  *  unsigned integer types of exactly 64, 32, 16, and 8 bits
>
>  *  respectively.
>
>  *ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t
>
>  *  signed integer types of exactly 64, 32, 16, and 8 bits
>
>  *  respectively.
>
>  *ev_uintptr_t, ev_intptr_t
>
>  *  unsigned/signed integers large enough
>
>  *  to hold a pointer without loss of bits.
>
>  *ev_ssize_t
>
>  *  A signed type of the same size as size_t
>
>  *ev_off_t
>
>  *  A signed type typically used to represent offsets within a
>
>  *  (potentially large) file
>
>  *
>
>  * @{
>
>  */
>
> #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  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:

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-28 Thread 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=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:

 *

 * 

 *   ev_uint64_t, ev_uint32_t, ev_uint16_t, ev_uint8_t

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

 *  respectively.

 *ev_int64_t, ev_int32_t, ev_int16_t, ev_int8_t

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

 *  respectively.

 *ev_uintptr_t, ev_intptr_t

 *  unsigned/signed integers large enough

 *  to hold a pointer without loss of bits.

 *ev_ssize_t

 *  A signed type of the same size as size_t

 *ev_off_t

 *  A signed type typically used to represent offsets within a

 *  (potentially large) file

 *

 * @{

 */

#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  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

[OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

2016-11-28 Thread 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 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=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

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

Re: [OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

[OMPI users] Issues building Open MPI 2.0.1 with PGI 16.10 on macOS

8 matches

Site Navigation

Mail list logo

Footer information