On Fri, Nov 14, 2014 at 8:51 PM, Konstantin Serebryany <konstantin.s.serebry...@gmail.com> wrote:
> It is true that we typically don't care about old kernels. Please note that 2.6.32 is still supported longterm release, not to mention that CentOS 5.x will be still supported for the next three years. gcc doesn't specify required kernel version to build, and it is expected that the default build - which includes sanitizers - doesn't break. The purpose of my build on CentOS 5.11 is to check just for this. So, if "you don't care about old kernels", it is YOUR responsibility as a patch submitter to check for unusual build requirements and disable the build for non-conforming environments. In practice, maintainers and people that care for their particular targets will help you with testing and patches, so "we disabled the library just because we don't bother with testing" with some target or build environment doesn't hold water here. > Those who care about older kernels are welcome to submit patches upstream Sure, but please note that the build environment is particular to gcc and that it probably differs substantially from the upstream build environment. The important difference is the default for the chosen compiler, which for gcc is to build with extensions, unless they are disabled with -std=... As evident from the header that crashed the build, external code outside gcc developers' control assume that these extensions are available, as they are default to compilation with gcc. > I don't think we ever rejected a reasonable patch that does not > significantly increase our maintenance headache. > Using -std=gnu++ for building these sources in GCC is potentially > leading to large delays in the merge process: > imagine that some of the code upstream gets incompatible with > -std=gnu++ for whatever reason. Please check the documentation, where it warns for C frontend that "By default, GCC provides some extensions to the C language that on rare occasions conflict with the C standard ...". There is no such warning for C++, so it is implied that -std=gnu++11 is a superset of -std=c++11: " By default, GCC provides some extensions to the C++ language; *Note Options Controlling C++ Dialect: C++ Dialect Options. Use of the '-std' option listed above will disable these extensions. You may also select an extended version of the C++ language explicitly with '-std=gnu++98' (for C++98 with GNU extensions) or '-std=gnu++11' (for C++11 with GNU extensions). The default, if no C++ language dialect options are given, is '-std=gnu++98'." Based on the above, I fail to see how C++11 conforming code would fail with -std=gnu++11. The effect of having -std=gnu++11 instead of -std=c++11 is, that some strict c++ limitations will be relaxed, and this is just what kernel code assumed. And as said elsewhere - we ARE compiling with gnu compiler, so using -std=gnu++11 should be the norm for the library compilation. Uros.
