On Wed, 4 Dec 2013, H.J. Lu wrote: > The kernel and glibc check should be done at the toplevel. > So what are the minimum kernel and glibc we want to > support?
Checking those at toplevel is tricky in general because you're checking something for the target rather than the host. You'd need to move the logic from gcc/configure.ac to compute target_header_dir and glibc_version_*, and GCC_GLIBC_VERSION_GTE_IFELSE from gcc/acinclude.m4, to something in toplevel config/ (and that logic depends on lots of other things in gcc/configure.ac). For binutils it's both easier to check (although the logic for binutils is also in gcc/acinclude.m4 at present) and more reasonable to require comparatively recent versions (for targets using binutils, which should cover everything supporting libsanitizer except Darwin) - I think there should be a minimum binutils version requirement generally when binutils is used with GCC, so we can reduce the need for conditionals on binutils features (unless of course the conditional code is still needed to support non-GNU assemblers and linkers for some target). It can be useful to build new tools for a target with old kernel and glibc in order to build binaries that will work on systems with a wide range of glibc versions. The oldest kernel and glibc versions I've used in that context with any post-4.3 GCC have been Linux 2.6.16 and glibc 2.4 (but the kernel headers were more recent than that, and this use case for old sysroots does *not* mean libsanitizer should necessarily be supported for them, simply that it's useful for the compiler and those libraries that may be used in production applications to be supported). If GCC were to desupport e.g. glibc before 2.4 you still get to deal with other libraries such as uClibc which pretends to be an older glibc (but again, you may well declare it unsupported for libsanitizer). -- Joseph S. Myers jos...@codesourcery.com
