[OMPI users] numaif.h present but not usable with openmpi-master-201702080209-bc2890e on Linux

Discussion:

Siegmar Gross

2017-02-08 12:01:33 UTC

Hi,

I have installed openmpi-master-201702080209-bc2890e on my "SUSE Linux
Enterprise Server 12.2 (x86_64)" with Sun C 5.14 and gcc-6.3.0.
Unfortunately, "numaif.h" isn't usable for "cc" while "gcc" has no
problems with that file. The file is available in /usr/local/include.

loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 165 grep numaif.h
log.configure.Linux.x86_64.64_gcc
checking numaif.h usability... yes
checking numaif.h presence... yes
checking for numaif.h... yes

loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_cc 168 grep numaif.h
log.configure.Linux.x86_64.64_cc
checking numaif.h usability... no
checking numaif.h presence... yes
configure: WARNING: numaif.h: present but cannot be compiled
configure: WARNING: numaif.h: check for missing prerequisite headers?
configure: WARNING: numaif.h: see the Autoconf documentation
configure: WARNING: numaif.h: section "Present But Cannot Be Compiled"
configure: WARNING: numaif.h: proceeding with the compiler's result
checking for numaif.h... no

I would be grateful, if somebody can fix the problem. Do you need anything
else? Thank you very much for any help in advance.

Kind regards

Siegmar

Jeff Squyres (jsquyres)

2017-02-08 14:19:51 UTC

Permalink

Siegmar --

This might be normal and expected (i.e., that the numaif.h that comes with your gcc may not be suitable for use with the Sun CC compiler). Is there any functionality difference between your two builds (with and without numaif.h support)?

The config.log from the cc build should include the specific reasons as to why configure thought numaif.h was not usable. Can you send it along?

Post by Siegmar Gross
Hi,
I have installed openmpi-master-201702080209-bc2890e on my "SUSE Linux
Enterprise Server 12.2 (x86_64)" with Sun C 5.14 and gcc-6.3.0.
Unfortunately, "numaif.h" isn't usable for "cc" while "gcc" has no
problems with that file. The file is available in /usr/local/include.
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 165 grep numaif.h log.configure.Linux.x86_64.64_gcc
checking numaif.h usability... yes
checking numaif.h presence... yes
checking for numaif.h... yes
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_cc 168 grep numaif.h log.configure.Linux.x86_64.64_cc
checking numaif.h usability... no
checking numaif.h presence... yes
configure: WARNING: numaif.h: present but cannot be compiled
configure: WARNING: numaif.h: check for missing prerequisite headers?
configure: WARNING: numaif.h: see the Autoconf documentation
configure: WARNING: numaif.h: section "Present But Cannot Be Compiled"
configure: WARNING: numaif.h: proceeding with the compiler's result
checking for numaif.h... no
I would be grateful, if somebody can fix the problem. Do you need anything
else? Thank you very much for any help in advance.
Kind regards
Siegmar
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

--
Jeff Squyres
***@cisco.com

Gilles Gouaillardet

2017-02-09 04:51:26 UTC

Permalink

Siegmar,

fwiw, on openSUSE Leap 42.2 (iirc, this is the free (aka CentOS-like)
version of SLES 12.2)

numaif.h is provided by libnuma-devel and is located in /usr/include

everything works fine with both GNU and Oracle compilers.

i noted that unlike GNU gcc, Oracle cc does not automatically search in
/usr/local/include.

Cheers,

Gilles

Post by Jeff Squyres (jsquyres)
Siegmar --
This might be normal and expected (i.e., that the numaif.h that comes with your gcc may not be suitable for use with the Sun CC compiler). Is there any functionality difference between your two builds (with and without numaif.h support)?
The config.log from the cc build should include the specific reasons as to why configure thought numaif.h was not usable. Can you send it along?

nfigure: WARNING: numaif.h: section "Present But Cannot Be Compiled"
configure: WARNING: numaif.h: proceeding with the compiler's result
checking for numaif.h... no

I would be grateful, if somebody can fix the problem. Do you need anything
else? Thank you very much for any help in advance.

Kind regards

Siegmar
_______________________________________________
users mailing list
***@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
</pre>
</blockquote>
<pre wrap="">

</pre>
</blockquote>
<br>
</body>
</html>

Siegmar Gross

2017-02-09 07:18:02 UTC

Permalink

Hi Gilles and Jeff,

adding "-I/usr/local/include" to CFLAGS and CXXFLAGS solved the problem.
I have a similar problem with "valgrind.h" and "cuda.h" for both compilers.

loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 155 grep valgrind.h
log.configure.Linux.x86_64.64_gcc
checking valgrind/valgrind.h usability... yes
checking valgrind/valgrind.h presence... no
configure: WARNING: valgrind/valgrind.h: accepted by the compiler, rejected by
the preprocessor!
configure: WARNING: valgrind/valgrind.h: proceeding with the compiler's result
checking for valgrind/valgrind.h... yes

loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 155 grep cuda.h
log.configure.Linux.x86_64.64_gcc
checking if --with-cuda is set... found (/usr/local/cuda/include/cuda.h)
checking cuda.h usability... no
checking cuda.h presence... no
checking for cuda.h... no
checking if MPI Extension cuda has C bindings... yes (required)
checking if MPI Extension cuda has mpif.h bindings... no
checking if MPI Extension cuda has "use mpi" bindings... no
checking if MPI Extension cuda has "use mpi_f08" bindings... no
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 156

I use the following configure commands.

../openmpi-master-201702080209-bc2890e/configure \
--prefix=/usr/local/openmpi-master_64_gcc \
--libdir=/usr/local/openmpi-master_64_gcc/lib64 \
--with-jdk-bindir=/usr/local/jdk1.8.0_66/bin \
--with-jdk-headers=/usr/local/jdk1.8.0_66/include \
JAVA_HOME=/usr/local/jdk1.8.0_66 \
LDFLAGS="-m64" CC="gcc" CXX="g++" FC="gfortran" \
CFLAGS="-m64 -I/usr/local/valgrind/include" \
CXXFLAGS="-m64 -I/usr/local/valgrind/include" \
FCFLAGS="-m64" \
CPP="cpp" CXXCPP="cpp" \
--enable-mpi-cxx \
--enable-cxx-exceptions \
--enable-mpi-java \
--with-cuda=/usr/local/cuda \
--with-hwloc=internal \
--without-verbs \
--with-wrapper-cflags="-std=c11 -m64" \
--with-wrapper-cxxflags="-m64" \
--with-wrapper-fcflags="-m64" \
--enable-debug \
|& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV.64_gcc

../openmpi-master-201702080209-bc2890e/configure \
--prefix=/usr/local/openmpi-master_64_cc \
--libdir=/usr/local/openmpi-master_64_cc/lib64 \
--with-jdk-bindir=/usr/local/jdk1.8.0_66/bin \
--with-jdk-headers=/usr/local/jdk1.8.0_66/include \
JAVA_HOME=/usr/local/jdk1.8.0_66 \
LDFLAGS="-m64 -mt -Wl,-z -Wl,noexecstack" CC="cc" CXX="CC" FC="f95" \
CFLAGS="-m64 -mt -I/usr/local/include -I/usr/local/valgrind/include" \
CXXFLAGS="-m64 -I/usr/local/include -I/usr/local/valgrind/include" \
FCFLAGS="-m64" \
CPP="cpp" CXXCPP="cpp" \
--enable-mpi-cxx \
--enable-cxx-exceptions \
--enable-mpi-java \
--with-cuda=/usr/local/cuda \
--with-hwloc=internal \
--without-verbs \
--with-wrapper-cflags="-m64 -mt" \
--with-wrapper-cxxflags="-m64" \
--with-wrapper-fcflags="-m64" \
--with-wrapper-ldflags="-mt" \
--enable-debug \
|& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV.64_cc

Can you fix the problems? Thank you very much for your help in advance.
I have attached the new config.log file for gcc.

Kind regards

Siegmar

Post by Gilles Gouaillardet
Siegmar,
fwiw, on openSUSE Leap 42.2 (iirc, this is the free (aka CentOS-like) version of
SLES 12.2)
numaif.h is provided by libnuma-devel and is located in /usr/include
everything works fine with both GNU and Oracle compilers.
i noted that unlike GNU gcc, Oracle cc does not automatically search in
/usr/local/include.
Cheers,
Gilles

Post by Jeff Squyres (jsquyres)
Siegmar --
This might be normal and expected (i.e., that the numaif.h that comes with
your gcc may not be suitable for use with the Sun CC compiler). Is there any
functionality difference between your two builds (with and without numaif.h
support)?
The config.log from the cc build should include the specific reasons as to why
configure thought numaif.h was not usable. Can you send it along?

On Feb 8, 2017, at 7:01 AM, Siegmar Gross
Hi,
I have installed openmpi-master-201702080209-bc2890e on my "SUSE Linux
Enterprise Server 12.2 (x86_64)" with Sun C 5.14 and gcc-6.3.0.
Unfortunately, "numaif.h" isn't usable for "cc" while "gcc" has no
problems with that file. The file is available in /usr/local/include.
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 165 grep
numaif.h log.configure.Linux.x86_64.64_gcc
checking numaif.h usability... yes
checking numaif.h presence... yes
checking for numaif.h... yes
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_cc 168 grep numaif.h
log.configure.Linux.x86_64.64_cc
checking numaif.h usability... no
checking numaif.h presence... yes
configure: WARNING: numaif.h: present but cannot be compiled
configure: WARNING: numaif.h: check for missing prerequisite headers?
configure: WARNING: numaif.h: see the Autoconf documentation
configure: WARNING: numaif.h: section "Present But Cannot Be Compiled"
configure: WARNING: numaif.h: proceeding with the compiler's result
checking for numaif.h... no
I would be grateful, if somebody can fix the problem. Do you need anything
else? Thank you very much for any help in advance.
Kind regards
Siegmar
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

nfigure: WARNING: numaif.h: section "Present But Cannot Be Compiled"
configure: WARNING: numaif.h: proceeding with the compiler's result
checking for numaif.h... no
I would be grateful, if somebody can fix the problem. Do you need anything
else? Thank you very much for any help in advance.
Kind regards
Siegmar
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Jeff Squyres (jsquyres)

2017-02-15 13:42:09 UTC

Permalink

Siegmar --

Sorry for the delay in replying.

You should actually put -I flags in CPPFLAGS and CXXCPPFLAGS, not CFLAGS and CXXFLAGS.

The difference is:

1. CFLAGS is given to the C compiler when compiling
2. CPPFLAFS is given to the C compiler when compiling and to the C preprocessor when preprocessing (i.e., in a standalone fashion / without compiling)

The same is true with CXXFLAGS and CXXCPPFLAGS.

More below.

Post by Siegmar Gross
adding "-I/usr/local/include" to CFLAGS and CXXFLAGS solved the problem.
I have a similar problem with "valgrind.h" and "cuda.h" for both compilers.
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 155 grep valgrind.h log.configure.Linux.x86_64.64_gcc
checking valgrind/valgrind.h usability... yes

The above test uses the C compiler, and therefore uses CFLAGS (and CPPFLAGS, but that's empty in your case). It therefore has the -I that you put in CFLAGS.

Post by Siegmar Gross
checking valgrind/valgrind.h presence... no

The above test uses the C preprocessor, but not the C compiler. Hence, it *only* uses CPPFLAGS (and *not* CFLAGS), and therefore does not have the -I indicating where the include files live.

The test therefore fails.

Post by Siegmar Gross
configure: WARNING: valgrind/valgrind.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: valgrind/valgrind.h: proceeding with the compiler's result
checking for valgrind/valgrind.h... yes
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 155 grep cuda.h log.configure.Linux.x86_64.64_gcc
checking if --with-cuda is set... found (/usr/local/cuda/include/cuda.h)
checking cuda.h usability... no
checking cuda.h presence... no
checking for cuda.h... no
checking if MPI Extension cuda has C bindings... yes (required)
checking if MPI Extension cuda has mpif.h bindings... no
checking if MPI Extension cuda has "use mpi" bindings... no
checking if MPI Extension cuda has "use mpi_f08" bindings... no
loki openmpi-master-201702080209-bc2890e-Linux.x86_64.64_gcc 156

This looks like it could be an error. Your config.log shows that it checks /usr/local/cuda/include for cuda.h (in the --with-cuda test), but then -I/usr/local/cuda/include is not added to CPPFLAGS for the "checking cuda.h usability / presence" tests.

Sylvain -- can you look into this?

--
Jeff Squyres
***@cisco.com

Siegmar Gross

2017-02-15 16:13:23 UTC

Permalink

Hi Jeff and Gilles,

thank you very much for your answers. I added -I flags for
"valgrind.h" und "cuda.h" to the CPPFLAGS and CXXCPPFLAGS
and related -L flags to LDFLAGS. Now the header files are
usable und I was able to build Open MPI master without errors
with gcc. Tomorrow I can test the installation.

Kind regards and thank you very much for your help once more

Siegmar

Post by Jeff Squyres (jsquyres)
Siegmar --
Sorry for the delay in replying.
You should actually put -I flags in CPPFLAGS and CXXCPPFLAGS, not CFLAGS and CXXFLAGS.
1. CFLAGS is given to the C compiler when compiling
2. CPPFLAFS is given to the C compiler when compiling and to the C preprocessor when preprocessing (i.e., in a standalone fashion / without compiling)
The same is true with CXXFLAGS and CXXCPPFLAGS.
More below.

The above test uses the C compiler, and therefore uses CFLAGS (and CPPFLAGS, but that's empty in your case). It therefore has the -I that you put in CFLAGS.

Post by Siegmar Gross
checking valgrind/valgrind.h presence... no

Jeff Squyres (jsquyres)

2017-02-15 16:23:02 UTC

Permalink

Did adding these flags to CPPFLAGS/CXXCPPFLAGS also solve the cuda.h issues?

Post by Siegmar Gross
Hi Jeff and Gilles,
thank you very much for your answers. I added -I flags for
"valgrind.h" und "cuda.h" to the CPPFLAGS and CXXCPPFLAGS
and related -L flags to LDFLAGS. Now the header files are
usable und I was able to build Open MPI master without errors
with gcc. Tomorrow I can test the installation.
Kind regards and thank you very much for your help once more
Siegmar

The above test uses the C compiler, and therefore uses CFLAGS (and CPPFLAGS, but that's empty in your case). It therefore has the -I that you put in CFLAGS.

Post by Siegmar Gross
checking valgrind/valgrind.h presence... no

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

--
Jeff Squyres
***@cisco.com

Siegmar Gross

2017-02-15 16:34:38 UTC

Permalink

Hi Jeff,

Post by Jeff Squyres (jsquyres)
Did adding these flags to CPPFLAGS/CXXCPPFLAGS also solve the cuda.h issues?

Yes, but it would be great if "configure" would add the flags
automatically when "--with-cuda=..." is available.

Kind regards

Siegmar

Post by Jeff Squyres (jsquyres)

The above test uses the C compiler, and therefore uses CFLAGS (and CPPFLAGS, but that's empty in your case). It therefore has the -I that you put in CFLAGS.

Post by Siegmar Gross
checking valgrind/valgrind.h presence... no

_______________________________________________
users mailing list
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Jeff Squyres (jsquyres)

2017-02-15 16:40:36 UTC

Permalink

Post by Siegmar Gross

Post by Jeff Squyres (jsquyres)
Did adding these flags to CPPFLAGS/CXXCPPFLAGS also solve the cuda.h issues?

Yes, but it would be great if "configure" would add the flags
automatically when "--with-cuda=..." is available.

Agreed. configure does this in other cases; it's a little odd if --with-cuda is not.

I'll add this to https://github.com/open-mpi/ompi/issues/2984.

--
Jeff Squyres
***@cisco.com

Siegmar Gross

2017-02-09 06:41:09 UTC

Permalink

Hi Jeff,

Post by Jeff Squyres (jsquyres)
This might be normal and expected (i.e., that the numaif.h that comes with
your gcc may not be suitable for use with the Sun CC compiler). Is there
any functionality difference between your two builds (with and without
numaif.h support)?

I didn't recognize any differences for my small programs.

Post by Jeff Squyres (jsquyres)
The config.log from the cc build should include the specific reasons as to
why configure thought numaif.h was not usable. Can you send it along?

I have attached it.

Kind regards and thank you very much for your help

Siegmar

Post by Jeff Squyres (jsquyres)