Can't build Boost 1.70.0 with pgc++

I’m attempting to build Boost 1.70.0 with pgc++ on CentOS 7.4.1708.

My pgc++ version is 15.7-0 64-bit target on x86-64 Linux -tp haswell.

I attempted to do this:

./ –prefix=/usr/local/boost_pgc
./b2 install --toolset=pgi --prefix=/usr/local/boost_pgc --with=all

The first command was successful, but the second resulted in multiple thousands of errors, with almost no targets successfully built. Does anyone have any clue what I’m doing wrong? I’d be happy to post the first few pages of errors.

Hi KurtMcCall31738,

Can you try using our latest release, PGI 19.4? I’m not sure PGI 15.7 can compile Boost but I have compiled Boost 1.69 recently with PGI 19.4 and did not have issues.

Note the free Community Edition of 19.4 can be found at:


Thanks, Mat. I’m looking into having 19.4 installed on our system. In the mean time, I tried compiling Boost 1.70 with pgc++ 17.7, and had some success. All but a handful of Boost targets were successfully built. Unfortunately, I am getting compilation errors deep within the Boost files when I try to compile my own code, for example:

“/usr/local/boost_pgc/include/boost/core/noncopyable.hpp”, line 42: error:
defaulted default constructor cannot be constexpr because the
corresponding implicitly declared default constructor would not be
BOOST_CONSTEXPR noncopyable() = default;

Does this look like something a more recent compiler would fix? And/or do I need to step back to an earlier Boost version? I know that this isn’t a lot of information to go on…

Does this look like something a more recent compiler would fix?

Possibly. We did do a lot work last year on getting most of Boost to work (there’s still some issues with the thread libraries, but I don’t think this is the problem here) and work with the Boost folks to so they didn’t use an old configuration (up until 1.69, they had some configuration what was based on our old pgCC compiler versus pgc++)

Another possibility is that your PGI install is configured to use and older GNU version. What GNU version do you have installed?

In order to object compatible with g++, we have to use their STL so are dependent upon the language level support by the GNU version pgc++ is configured to use. For example, g++ did not fully support C++11 until 4.9.3, C++14 til the mid 5.x release, and I believe C++17 until 7.x (though I may be slightly off of this). It’s possible that this is causing the issue and you’ll need to reconfigure pgc++ to use a newer GNU STL.

The PGI configuration information is stored in a file called “localrc” found in your PGI installation’s “bin” directory. To update the PGI configuration to use a different GNU installation, run the following command:

makelocalrc -x -d . -gcc /path/to/gnu/bin/gcc -g++ /path/to/gnu/bin/g++ -g77 /path/to/gnu/bin/gfortran

This will create a new “localrc” file in your local directory. From here, you can set the PGI environment variable “PGI_LOCALRC” to the fully qualified path to this localrc file.


Mat, our g++ version is g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16). I am unclear on how the pgc++
installation process depends on the GCC STL. Just the general idea would help.

our g++ version is g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)

That could be a problem given 4.8.5 didn’t fully support C++11. Not sure it’s the core problem, but you can try configuring pgc++ to use a newer GNU, assuming you have a newer GNU installed.

The steps to configure pgc++ to use a different GNU STL:

  • Set your PATH to include the new GNU version
  • Run “makelocalrc -x -d . -gcc /path/to/gnu/bin/gcc -g++ /path/to/gnu/bin/g++ -g77 /path/to/gnu/bin/gfortran”
  • Optionally move the resulting “localrc” file to a new directory and rename it. For example “localrc.gnu83”
  • Set the environment variable “PGI_LOCALRC=/path/to/my/”

I am unclear on how the pgc++ installation process depends on the GCC STL.

Not 100% sure what you’re asking, but if I’m off, please restate.

In general, objects compiled by different C++ compilers are not compatible. Things like how exception handling is done, name mangling, and the STL are not defined by the C++ standard so each implementation is free to decide how these are done.

Awhile ago, we had a lot of user requests to be able to link g++ compiled code (in particular libraries) with PGI’s C++ compiler (pgCC). Hence we revamped our compiler (pgCC became pgc++) to use the same exception handling and name mangling, but also this then required us to use the GNU STL. The good news is that pgc++ is now object compatible with g++, but do now have this dependency on the GNU STL.