config/svr4.h

[Joseph S. Myers]

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
joseph@codesourcery.com