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?
>
>
next prev parent 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).