Discrepancies between Debian and Ubuntu compiler install


I compiled code on Ubuntu (20) and Debian (bullseye) and noticed some discrepancies which I would like to know if they are defined behavior.
Note that the same packages containing the HPC SDK was installed on both machines (nvhpc-22-1_22.1_amd64.deb & nvhpc-2022_22.1_amd64.deb).

  • On Ubuntu cmake 3.20 ~ recognizes the compiler freshly installed from https://developer.nvidia.com/nvidia-hpc-sdk-downloads as NVHPC (using CMAKE_CXX_COMPILER_ID), on Debian (cmake 3.18) its recognized as PGI. I know nvc is derived from pgi but why the discrepancy ?

  • On Debian bullseye I can’t compile due to the following error:

"/usr/include/x86_64-linux-gnu/bits/socket.h", line 285: error: incomplete type is not allowed
      __extension__ unsigned char __cmsg_data __flexarr; /* Ancillary data.  */

Without going too deep into header stuff, I noticed that the -A option (aka, “Accept ANSI standard C++”) on pgi triggers the issue. When using CMake you can switch ON/OFF the CXX_EXTENSIONS property which controls which version of a cpp standard you want to compile for (-std=c++14 for instance). When turned ON, this property can be translated by gnuc++XX (gnuc++14 for instance) on clang and gcc; that is, “allow” language extensions. When turned OFF, the translation would be c++XX (c++14 for instance). On the HPC SDK, CMake 3.18 and Debian bullseye and using nvc++, when turned ON this is translated to --gnu_extensions, when OFF, this option is translated to -A.

TLDR; The -Aoption breaks the gnu libc. This is problematic at least because pgi defines __GNUC__, and because even if g++ is given -std=c++14, that is, no c++ extensions (which is the opposite of gnu++14) it can consume the gnu libc.

The following code compiled using nvc++ dummy.cc -c -A will trigger the issue):

#include <netdb.h>


Hi EtienneM,

Kitware, the makers of cmake, incorrectly added the “-A” flag a bit ago. Once found that it was causing problems, we added a request to have it removed. See:

I’m not sure exactly which cmake release this got in, but I presume 3.20 which accounts for the difference you’re seeing.

We’ve also been working with them to update cmake to recognize NVHPC rather than just PGI.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.