Helloļ¼
Thanks Kai Ruottu very much for the detailed explanation.
At first glance I thought that I might go too far in wrong direction,
fortunately, not so bad.
Firstly I have to admit that I made a mistake. I will show it by listing
codes from cppdefault.c and gcc makefile. All are based on gcc-3.4.2
and "build=host != target" GCC built automatically using buildroot.
>From GCC's makefile, there are some variables passed when compiling
cppdefault.c:
PREPROCESSOR_DEFINES = \
-DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
-DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
-DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\"
\
-DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \
-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
-DCROSS_INCLUDE_DIR=\"$(CROSS_SYSTEM_HEADER_DIR)\" \
-DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
cppdefault.o: cppdefault.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
cppdefault.h Makefile
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(PREPROCESSOR_DEFINES) \
-c $(srcdir)/cppdefault.c $(OUTPUT_OPTION)
There are three important macros : LOCAL_INCLUDE_DIR, CROSS_INCLUDE_DIR
and TOOL_INCLUDE_DIR.
and in cppdefault.c there are following codes:
#if defined (CROSS_COMPILE) && !defined (TARGET_SYSTEM_ROOT)
# undef LOCAL_INCLUDE_DIR
# undef SYSTEM_INCLUDE_DIR
# undef STANDARD_INCLUDE_DIR
#else
# undef CROSS_INCLUDE_DIR
#endif
const struct default_include cpp_include_defaults[]
= {
/* some other dirs not relevant here */
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1 },
#endif
#ifdef GCC_INCLUDE_DIR
/* This is the dir for fixincludes and for gcc's private headers. */
{ GCC_INCLUDE_DIR, "GCC", 0, 0, 0 },
#endif
#ifdef CROSS_INCLUDE_DIR
/* One place the target system's headers might be. */
{ CROSS_INCLUDE_DIR, "GCC", 0, 0, 0 },
#endif
#ifdef TOOL_INCLUDE_DIR
/* Another place the target system's headers might be. */
{ TOOL_INCLUDE_DIR, "BINUTILS", 0, 1, 0 },
#endif
#ifdef SYSTEM_INCLUDE_DIR
/* Some systems have an extra dir of include files. */
{ SYSTEM_INCLUDE_DIR, 0, 0, 0, 1 },
#endif
#ifdef STANDARD_INCLUDE_DIR
/* /usr/include comes dead last. */
{ STANDARD_INCLUDE_DIR, STANDARD_INCLUDE_COMPONENT, 0, 0, 1 },
#endif
{ 0, 0, 0, 0, 0 }
};
So with CROSS_COMPILE defined and TARGET_SYSTEM_ROOT not ,
It will un-define LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR
in cppdefault.c.
And it will left two directories defined by CROSS_INCLUDE_DIR
and TOOL_INCLUDE_DIR.
Here is my mistake that I just payed attention to CROSS_INCLUDE_DIR
and missed TOOL_INCLUDE_DIR in previous message.
But it might does not matter because It seems the target GCC will search headers
in directories defined by CROSS_INCLUDE_DIR and TOOL_INCLUDE_DIR, which raises
another question as following.
The GCC makefile passed macro "TOOL_INCLUDE_DIR" set to
"$(gcc_tooldir)/include",
But eventually there is no such directory in installation directory of
target GCC.
While there is directory defined by
CROSS_INCLUDE_DIR="$(CROSS_SYSTEM_HEADER_DIR)"
with "CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include".
(In your explanation, the use of CROSS_INCLUDE_DIR is kinda mistake.
Anyway the sources I used are really old(buildroot-070118 daily
snapshot and gcc-3.4.2),
the latest buildroot configured gcc with "--with-sysroot",
So don't have to bother with it.)
It seems the target GCC searches the right directory $(gcc_tooldir)/sys-include,
through the macro CROSS_INCLUDE_DIR, rather than TOOL_INCLUDE_DIR in this case.
It works alright maybe because CROSS_INCLUDE_DIR and TOOL_INCLUDE_DIR are just
two macro-name except if CROSS_INCLUDE_DIR is used in other places, which I
don't know.
On Mon, Dec 8, 2008 at 2:12 AM, Kai Ruottu <[EMAIL PROTECTED]> wrote:
> Cheng bin wrote:
>>
>> Hi All:
>> About "--with-sysroot" option, I got some understanding
>> following but not sure about it.
>> All words are based on gcc-3.4.2.
>> For a native gcc, There are three important macro
>> LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR
>> and STANDARD_INCLUDE_DIR. Gcc built will search headers in directories
>> defined by these macro.
>> For a "build=host != target" cross gcc, there are two cases:
>> Firstly, If configured without option "--with-sysroot", the gcc
>> built will search headers in directory defined
>> by macro CROSS_INCLUDE_DIR.
>
> A cross GCC has traditionally searched its target headers from TWO
> directories :
>
> $tooldir/include - this is the equivalent to STANDARD_INCLUDE_DIR
> $tooldir/sys-include - this is the equivalent to SYSTEM_INCLUDE_DIR
>
> So:
>
> o for the usual '/usr/include' there is the usual '$tooldir/include'.
> Things like the free 'newlib' C library will install their headers
> into this directory.
>
> o for the unusual SYSTEM_INCLUDE_DIR equivalent there should be an
> empty 'optional' place in a cross GCC. The 'GCC internals' manual
> tells that GCC will not install anything there. People are free to
> put their "system specific" headers there, "standard headers" should
> be in the '$tooldir/include'. Newlib for instance doesn't include
> any chip-specific headers (to describe their built-in I/O addresses
> etc) for "embedded" targets. Targets like Cygwin and MinGW do include
> separate "w32api" headers which quite clearly belong to this "system
> specific" group, the usual 'stdio.h', 'stdlib.h' then don't...
>
> The $tooldir is the '$prefix/$target', so the directories there are
> common for the target, no GCC-version dependency normally. But the
> built-in search dirs ("$target-gcc -print-search") in GCC include
> some GCC-version dependent places below $tooldir for libraries, for
> target headers only the two previous are available...
>
> The LOCAL_INCLUDE_DIR ('$prefix/include') then could be common for all
> GCCs using the same $prefix. In the GCC sources this place has been
> disabled for cross GCCs but enabling it isn't any rocket science, just
> editing the 'gcc/cppdefaults' a little...
>
>> Everything is ok if CROSS_INCLUDE_DIR is right and it is makefile's
>> responsibility to define and pass this macro to gcc(such cppdefault.c
>> etc.).
>
> I remember TOOL_INCLUDE_DIR pointing to the '$tooldir/include'. Using
> the CROSS_INCLUDE_DIR for anything is absolutely wrong! That using it
> has been wrong more than 10 years, doesn't change the situation in any
> way. There has been a horrible bug and someone who CAN fix the GCC
> sources should fix this "eternal bug"!
I've just went into GCC's internal for short time, So don't know anything
about the "eternal bug"raised by using CROSS_INCLUDE_DIR. Could you
please point it out or a URL will be OK. Thanks.
>> Secondly, if gcc is configured with option "--with-sysroot=XXX",
>> it will search header files in directories
>> defined by macro LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR and
>> STANDARD_INCLUDE_DIR, just like native compiler do, but start from
>
>> directory defined by macro TARGET_SYSTEM_ROOT.
>
> Quite common target for a "cross GCC" is a target for which there is no
> "native GCC". The cross GCC is first and the only possible type of GCC
> for them! Someone could even claim this type, "bare GCC", being the
> most common among cross GCCs... In order to take the SYSROOT in any use,
> the cross GCC builder should first imagine the unexisting "native GCC"
> for the target in question :( Targets like 'arc-elf', 'arm-elf',
> 'avr-elf', 'h8300-elf', 'mips-elf',... don't have any native GCCs for
> them...
>
>> Though both methods works for cross compiler, the second one
>> makes it possible to near the gap between native and cross compiler.
>
> The idea comes from the attitude: "In the very beginning there was
> nothing and from this emptiness the gods created the native GCCs!"
> Using proprietary non-GNU "native C compilers" of course! Creating
> cross GCCs with the non-GNU C compilers then shouldn't work :(
>
>> I think that is why gcc developers added "with-sysroot" configure
>
>> option.
>
> IMHO the other route : Changing the native GCCs to be "just like cross
> GCCs", would have been much better! Of course this would have required
> bettering the cross GCC install scheme. Producing GCCs as cross GCCs
> make them "portable": once produced GCC could be copied onto a newer
> host and used there. Copying native GCCs onto newer hosts isn't that
> easy :( For instance taking the GCC and C library etc from RHL 7.3 and
> using the old tools to produce apps for RHL 7.3 on some uptodate Fedora
> Linux...
This view is surely more useful though there might be the two
sides of the coin.
> Of course people have been free to produce their self-made tools for
> their own taste. Maybe it was 10 years ago when I last made a native
> GCC, after that only cross GCCs... The oldest GCCs in my Linux maybe
> were produced for RHL 6.2 with its glibc-2.1.3. Some targets stopped
> to be supported before gcc-3.0, so I have quite many gcc-2.7's and
> gcc-2.9's still fully working...
>
> Ok, we are talking about "free sources" and people are free to change
> them if they don't like what they are getting via the defaults! The
> weird use of CROSS_INCLUDE_DIR :
>
> http://gcc.gnu.org/onlinedocs/gccint/Header-Dirs.html#Header-Dirs
>
> cannot be explained in any sane way :( One can only nag this "feature"
> or try to get rights to fix the current situation... Or stop nagging
> and just fix the local sources to behave more sane...
>
Thanks again for your patience.
