From: "Joseph S. Myers" <joseph@codesourcery.com>
To: gcc@gcc.gnu.org
Subject: config/svr4.h
Date: Fri, 03 Dec 2010 22:40:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1012032224020.3292@digraph.polyomino.org.uk> (raw)
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
next reply other threads:[~2010-12-03 22:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-03 22:40 Joseph S. Myers [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-04-12 12:43 config/svr4.h John Carr
1998-04-12 18:31 ` config/svr4.h Jeffrey A Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1012032224020.3292@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).