public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/18469] configure incorrectly defines gid_t
Date: Tue, 17 Dec 2013 23:26:00 -0000	[thread overview]
Message-ID: <bug-18469-4-1uZxIH4JXK@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-18469-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 16 Dec 2013, ktietz at gcc dot gnu.org wrote:

> The macros required in crtstuff.c are:
> - HAVE_GAS_HIDDEN
> - HAVE_LD_EH_FRAME_HDR

Various target macros used in target code as well as host code should, I 
suggest at <http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration>, be 
handled via the compiler predefining macros if -fbuilding-libgcc, with 
those predefines being used in target code instead of the macros from host 
tm.h.  (The exact list of host-side tm.h macros used in target code there 
may be out of date, but I expect it's still pretty close to what needs 
fixing to stop target code needing that host-side header.)

I suggest the same solution for configure-determined macros used by target 
code: predefine something if -fbuilding-libgcc, and use that predefine in 
target code.  That avoids duplicating the configure detection.

I definitely encourage cleaning things up in this area to improve the 
host/target separation in the build system.  I don't think any of the 
cases of target (or configure) macros used in target code are hard to fix; 
it just requires careful work on working out the right conversion for each 
of the many macros affected, making sure in every case that no files 
needing updating are missed out.


  parent reply	other threads:[~2013-12-17 23:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-18469-4@http.gcc.gnu.org/bugzilla/>
2013-12-16 20:09 ` ktietz at gcc dot gnu.org
2013-12-17 23:26 ` joseph at codesourcery dot com [this message]
2020-10-13  2:34 ` kargl at gcc dot gnu.org
2020-10-15 20:02 ` egallager at gcc dot gnu.org
2020-10-15 20:09 ` redi at gcc dot gnu.org
2022-05-24 14:52 ` egallager at gcc dot gnu.org
2004-11-13 21:01 [Bug target/18469] New: " aaronavay62 at aaronwl dot com
2004-11-13 21:06 ` [Bug target/18469] " pinskia at gcc dot gnu dot org
2005-02-10 20:53 ` ebotcazou at gcc dot gnu dot org
2005-05-12  2:11 ` pinskia at gcc dot gnu dot org

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=bug-18469-4-1uZxIH4JXK@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).