https://libc.llvm.org/compiler_support.html is not clear about building libc vs building against libc headers

[frobtech]

The documentation page on compiler support is not very clear. The only things it mentions explicitly are implementation issues, indicating that it may only be addressing what compilers can be used to build libc. For libc more than anything else, it's important to distinguish requirements for building libc from requirements for compiling against its headers and linking against its library artifacts. Every serious libc supports users compiling against headers and linking against libraries to use a very wide variety of compilers and not a specific supported list, but rather any standards-conforming compiler. The set of compilers supported for building libc itself can be much more constrained.

It is reasonable for libc to largely follow libc++'s compatibility requirements as to building the library itself. For using the headers and libraries, even libc++ does not claim such strict requirements. Rather, they say that there are no guarantees about compilers that aren't being tested by the project.

In the context of libc, unlike libc++, there is really no need to use anything in public headers that can't be widely compatible with any compiler. The best policy for users is to have headers likely to work with just about any compiler in any mode.

[llvmbot]

@llvm/issue-subscribers-libc

Author: Roland McGrath (frobtech)

The documentation page on compiler support is not very clear. The only things it mentions explicitly are implementation issues, indicating that it may only be addressing what compilers can be used to build libc. For libc more than anything else, it's important to distinguish requirements for building libc from requirements for compiling against its headers and linking against its library artifacts. Every serious libc supports users compiling against headers and linking against libraries to use a very wide variety of compilers and not a specific supported list, but rather any standards-conforming compiler. The set of compilers supported for building libc itself can be much more constrained.

It is reasonable for libc to largely follow libc++'s compatibility requirements as to building the library itself. For using the headers and libraries, even libc++ does not claim such strict requirements. Rather, they say that there are no guarantees about compilers that aren't being tested by the project.

In the context of libc, unlike libc++, there is really no need to use anything in public headers that can't be widely compatible with any compiler. The best policy for users is to have headers likely to work with just about any compiler in any mode.

[nickdesaulniers]

The best policy for users is to have headers likely to work with just about any compiler in any mode.

It is not worth supporting users that may have just about any compiler in any mode. It is worth defining which compilers and compiler versions we do support (both for building the libc, and consuming the libc headers) which aught to be tested continuously.

I plan to revisit our buildbots soon, at which point I plant to raise our minimum supported compilers required. Once that's straightened out, I will revise our documentation around supported versions.