public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "He Yunlong-B20256" <B20256@freescale.com>
To: "Kai Ruottu" <kai.ruottu@wippies.com>, "Andrew Haley" <aph@redhat.com>
Cc: <gcc-help@gcc.gnu.org>
Subject: RE: One question about gcc fix_includes
Date: Mon, 07 Dec 2009 08:25:00 -0000	[thread overview]
Message-ID: <6368A20E269B6B4CA5ABB15E14F34C8294AA6C@zch01exm22.fsl.freescale.net> (raw)
In-Reply-To: <4B163746.8070600@wippies.com>

Hi, Kai & Andrew,

	Anyway, for one cross-compiler, even building gcc causes to
"fix" header files again, the header files should be from the
cross-compiler itself, instead of /usr/include, is it right?

	If possible, I think gcc build process should be updated as:

	1. use header files from cross-compiler.   (Does current gcc
support this? How to do?)
	2. if the headerfiles have been fixed already, skip fixing and
copy them directly.

B.R.
Harry

> -----Original Message-----
> From: Kai Ruottu [mailto:kai.ruottu@wippies.com] 
> Sent: Wednesday, December 02, 2009 5:46 PM
> To: He Yunlong-B20256
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: One question about gcc fix_includes
> 
> He Yunlong-B20256 wrote:
> > Hi, Experts,
> >
> > 	We are using one cross-compiler to compile native gcc, 
> in out test, 
> > we found that gcc will created "fixed includes" from host 
> glibc header 
> > files, I think they should come from the header files inside of the 
> > cross-compiler, can anyone confirm that?
> >   
> 
> Ok, maybe the headers could be fixed once again - they were 
> already fixed during the cross- compiler build - but why?  
> Maybe all the target libraries could be built again - they 
> were already built during the cross-compiler build - but why?
> 
> I myself have never thought that in a Canadian Cross these 
> tasks should be done again, I have only produced the required 
> executables for the new $host and been happy with them alone...
> 
> Nowadays the majority of the by GCC-build produced $target 
> stuff resides in :
> 
>     $prefix/lib/gcc/$target/$gcc-version
> 
> separate from the primary $host ($build host) stuff in :
> 
>     $prefix/libexec/gcc/$target/$gcc-version
> 
> including the fixed target headers in 'include-fixed'.  So 
> what is the problem with just copying this directory "as it 
> is" onto the secondary $host ?
> 
> Furthermore the GCC install wouldn't copy the binutils 
> neither the target C libraries onto the another, 'secondary', 
> $host,  so in any case there will be some manual 
> work :(   What to
> automatize and what not, that's the question...
> 
> Generally in some cases like those handling two "full 
> systems"  like Linux and Solaris, cross- producing tools for 
> another, could benefit from pre-installing the stuff onto the 
> $build system for easy tarballing, ie installing it onto the 
> already existing $sysroot made for the "native"
> stuff like its base C library.  But should the stuff be 
> produced first again with the cross-compiler or simply be 
> copied from the cross-compiler?
> 
> 

  reply	other threads:[~2009-12-07  6:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30 23:19 Warning when using const pointer to fixed size array Aaron Rocha
2009-11-30 23:38 ` Thomas Martitz
2009-11-30 23:47   ` me22
2009-12-01  0:05     ` Thomas Martitz
2009-12-01  0:08       ` me22
2009-12-01  0:24         ` Aaron Rocha
2009-12-01  0:44           ` me22
2009-12-01  2:29             ` One question about gcc fix_includes He Yunlong-B20256
2009-12-01  9:34               ` Andrew Haley
2009-12-02  2:37                 ` He Yunlong-B20256
2009-12-02  9:40                   ` Andrew Haley
2009-12-02  9:43               ` Kai Ruottu
2009-12-07  8:25                 ` He Yunlong-B20256 [this message]
2009-12-01  0:08       ` Warning when using const pointer to fixed size array Thomas Martitz
2009-12-01  9:52 ` Andrew Haley
2009-12-01 14:54   ` Aaron Rocha
2009-12-01 15:08     ` Sergei Organov
2009-12-01 15:19       ` me22
2009-12-01 16:25         ` Sergei Organov
2009-12-01 16:29           ` me22
2009-12-01 16:42             ` Sergei Organov
2009-12-01 15:33     ` Andrew Haley
2009-12-01 15:43       ` Aaron Rocha
2009-12-01 16:22         ` Andrew Haley
2009-12-01 18:16           ` Aaron Rocha
2009-12-01 15:57     ` John (Eljay) Love-Jensen
2009-12-01 15:59       ` John (Eljay) Love-Jensen
2009-12-01 16:00       ` Andrew Haley

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=6368A20E269B6B4CA5ABB15E14F34C8294AA6C@zch01exm22.fsl.freescale.net \
    --to=b20256@freescale.com \
    --cc=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=kai.ruottu@wippies.com \
    /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).