The configuration header config/svr4.h is used 74 times in config.gcc (plus one reference in a comment).
This header is nominally "Operating system specific defines to be used when targeting GCC for some generic System V Release 4 system". GCC no longer supports any generic System V Release 4 systems (various generic such targets were obsoleted in 4.3). Instead, this header is used for various configurations with nothing much in common including bare-metal systems, GNU/Linux, uClinux, RTEMS, HP-UX, VxWork, NetBSD, OpenBSD, NetWare, QNX and TPF - but for many of these, only for a subset of the supported architectures. I don't believe there is any common essence of SVR4-ness among currently supported targets such that it makes sense to have a common header. Figuring out what options in specs should be added to .opt file for what targets also requires going through all 74 cases to find which specs in this header are overridden when (any serious hookization of SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE would also require figuring out just when the definitions in this header are relevant). Thus, I propose to remove this header, moving parts of it that are actually relevant and used for individual targets into more appropriate headers for those targets. For the target macros AS_NEEDS_DASH_FOR_PIPED_INPUT, MD_EXEC_PREFIX, MD_STARTFILE_PREFIX, TARGET_POSIX_IO I propose to do this on a per-macro basis (taking MD_*_PREFIX together), removing macro definitions from this header and putting them in better places for the targets that need them. For the other macros I propose to go through the targets one by one, and for each target put the required macros in another header and stop that target using svr4.h. svr3.h in principle has the same issue (no "generic System V Release 3 system" support in GCC), but as (a) it defines no specs and (b) it's only used by one target (mcore-*-pe*) it doesn't really cause problems in practice. Thus I don't currently plan to do anything with it. (I am not expecting any comments on this plan; this message is simply to avoid repeating what's wrong with svr4.h and what I am doing about it in every individual patch submission.) -- Joseph S. Myers jos...@codesourcery.com
