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.