RFE: libstdc++ enforcement for clang compilers on Linux

[Paul Hargrove]

Issue 347 requests improvements to how we detect/enforce the minimum required g++ (for its libstdc++) with Intel compilers. Meanwhile, we have no detection at all for Clang compilers on Linux (failing instead when building libupcxx.a).

[Paul Hargrove]

There are __GNUC__ markings in the preprocessed output of clang/clang++, but they define the front-end compatibility and do not track the gcc install specified

So far I see only means to query the header and library search paths.
However, determining a g++ version from than requires knowing the layout of a GCC install.
So, no immediate plans to approach things from that direction.

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Paul Hargrove]

The following looks relevant, not just to Clang++ but in general:

// The current version of the C++ library in compressed ISO date format.
#define __GLIBCXX__ 20170704

That is the version defined in the bits/c++config.h header in GCC 6.4.0.
Meanwhile GCC 6.3.0 has 20161221.

Further reading reveals, however, that this date-based version is not safe/sufficient. Indeed GCC 5.5 has a later (Oct, 2017) date and GCC 7.1 has an earlier (May, 2017) date than 6.4 (Jul, 2017).

Since GCC 7, there is a _GLIBCXX_RELEASE with the major version (defined in the same file). Combining that with the monotonic (documented) values of __GLIBCXX__ within each major release, one can identify the libstdc++ for any GCC version 7.x or newer.

If we can find a reliable means to identify the C++ headers from GCC 5.5 (and the snapshots leading up to it, as are often used by distros), then we may have a reliable compiler-independent means to identify the GCC version supplying the C++ headers for a non-GNU compiler. However, the extensive libstdc++ documentation does not seem to provide any explicit means to do so. However, there are almost certainly feature checks configure could use to distinguish libstdc++ headers in GCC 5 from those in GCC 6.

Alternatively, raising the libstdc++ floor to GCC 7.1.0 for non-GNU compilers (as already done for Cray systems) may be an option to enable an unambiguous configure check for an acceptable GNU libstdc++.

Yet another alternative is to just ignore GCC 5.5, and use (__GLIBCXX__ >= 20170704) || defined(_GLIBCXX_RELEASE). This expression will yield the correct results for all GCC 6.x and newer, and for 5.4 and older.

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Paul Hargrove]

As noted in Slack discussions, this issue applies not only to "LLVM Clang", but also other compilers based on Clang such as Intel's oneAPI compilers. So, the eventual solution should not be exclusive to the "LLVM Clang" compiler family.

[Paul Hargrove]

This is no longer under consideration for the 2021.9.0 release. Rolling over to 2022.3.0.

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Paul Hargrove]

@Colin MacLean has noted a need to ensure this does not break linking with llvm's libc++ in lieu of the GNU libstdc++. This is probably just a matter of accepting the case in which __GLIBCXX__ is undefined

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

Clear past Milestone for open issues