Warning when using const pointer to fixed size array

Warning when using const pointer to fixed size array

[Aaron Rocha]

I am using :

$ gcc -dumpversion
4.2.4
$ gcc -dumpmachine
x86_64-linux-gnu

As expected, the following code does not generate any warnings when compiling with -Wall:

int main() {

   int number = 0;

   const int * const t = &number;

   return *t;
}

However, this code does:

int main() {

   int array[9] = {0};

   const int (* const p)[9] = &array;

   return (*p)[0];
}

$ gcc -Wall ./tst2.c 
./tst2.c: In function ‘main’:
./tst2.c:7: warning: initialization from incompatible pointer type

In order to eliminate this warning, I have to declare array as:

const int array[9];

Why is this the case though? In both examples, I am trying to use a const pointer to access a non-const variable for read-only purposes. Isn't this supposed to be OK?

Thanks



      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

Re: Warning when using const pointer to fixed size array

[Thomas Martitz]

Am 01.12.2009 00:19, schrieb Aaron Rocha:
> I am using :
>
> $ gcc -dumpversion
> 4.2.4
> $ gcc -dumpmachine
> x86_64-linux-gnu
>
> As expected, the following code does not generate any warnings when compiling with -Wall:
>
> int main() {
>
>     int number = 0;
>
>     const int * const t =&number;
>
>     return *t;
> }
>
> However, this code does:
>
> int main() {
>
>     int array[9] = {0};
>
>     const int (* const p)[9] =&array;
>    


What address are you taking? "array" already stands for the address of 
the first element (and is hence sort of a pointer). I'm not sure you can 
take the address of the array name as I think it doesn't have one.

Maybe you want &array[0]?

Re: Warning when using const pointer to fixed size array

[me22]

2009/11/30 Thomas Martitz <thomas.martitz@student.htw-berlin.de>:
>
> What address are you taking? "array" already stands for the address of the
> first element (and is hence sort of a pointer). I'm not sure you can take
> the address of the array name as I think it doesn't have one.
>

You can, actually:

    int main() {
        int a[4];
        int (*p)[4] = &a;
    }

Re: Warning when using const pointer to fixed size array

[Thomas Martitz]

Am 01.12.2009 00:46, schrieb me22:
> 2009/11/30 Thomas Martitz<thomas.martitz@student.htw-berlin.de>:
>    
>> What address are you taking? "array" already stands for the address of the
>> first element (and is hence sort of a pointer). I'm not sure you can take
>> the address of the array name as I think it doesn't have one.
>>
>>      
> You can, actually:
>
>      int main() {
>          int a[4];
>          int (*p)[4] =&a;
>      }
>    


I didn't try gcc, but visual studio compiler gives an error on that one.

Re: Warning when using const pointer to fixed size array

[me22]

2009/11/30 Thomas Martitz <thomas.martitz@student.htw-berlin.de>:
>
> I didn't try gcc, but visual studio compiler gives an error on that one.
>

I tried it in gcc 4.3.2, where it worked fine.

Re: Warning when using const pointer to fixed size array

[Thomas Martitz]

Am 01.12.2009 01:05, schrieb Thomas Martitz:
> Am 01.12.2009 00:46, schrieb me22:
>> 2009/11/30 Thomas Martitz<thomas.martitz@student.htw-berlin.de>:
>>> What address are you taking? "array" already stands for the address 
>>> of the
>>> first element (and is hence sort of a pointer). I'm not sure you can 
>>> take
>>> the address of the array name as I think it doesn't have one.
>>>
>> You can, actually:
>>
>>      int main() {
>>          int a[4];
>>          int (*p)[4] =&a;
>>      }
>
>
> I didn't try gcc, but visual studio compiler gives an error on that one.

Nevermind, I just tried copy&pasting yours and it worked. I guess I used 
something slightly different.

Re: Warning when using const pointer to fixed size array

[Aaron Rocha]

This is the correct syntax when declaring a pointer to a fixed size array.
It is not something you usually see in C code but it is perfectly legal
syntax.

Back to my original question though. Why does gcc give that warning? It 
should be legal to point a const pointer to a non-const variable and use 
the pointer for read-only access, right? So why the warning? Is this a bug 
in GCC?

Cheers

--- On Mon, 11/30/09, me22 <me22.ca@gmail.com> wrote:

> From: me22 <me22.ca@gmail.com>
> Subject: Re: Warning when using const pointer to fixed size array
> To: "Thomas Martitz" <thomas.martitz@student.htw-berlin.de>
> Cc: gcc-help@gcc.gnu.org
> Received: Monday, November 30, 2009, 5:08 PM
> 2009/11/30 Thomas Martitz <thomas.martitz@student.htw-berlin.de>:
> >
> > I didn't try gcc, but visual studio compiler gives an
> error on that one.
> >
> 
> I tried it in gcc 4.3.2, where it worked fine.
> 


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

Re: Warning when using const pointer to fixed size array

[me22]

2009/11/30 Aaron Rocha <hxdg21@yahoo.com>:
>
> Back to my original question though. Why does gcc give that warning? It
> should be legal to point a const pointer to a non-const variable and use
> the pointer for read-only access, right? So why the warning? Is this a bug
> in GCC?
>

I'm unsure, but it's possible that the problem is that you're not
using a pointer to a const array of non-mutable elements, but a
pointer to non-const array with const elements.  (I have no idea how
"deep" const is with array types.)

It makes me think of this situation, though I don't know whether it applies:
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17

But that said, apparently this gives the warning too:

  int main() {
    typedef int atype[9];
    atype array = {};
    atype const* const p = &array;
    return (*p)[0];
  }

Which definitely wouldn't for a non-array type.

One question about gcc fix_includes

[He Yunlong-B20256]

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?

Thanks
Harry

Re: One question about gcc fix_includes

[Andrew Haley]

He Yunlong-B20256 wrote:

> 	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?

That doesn't sound right.  gcc is supposed to fixinclude the headers
from the C library for the target.  It's possible you failed to
provide them.

Andrew.

Re: Warning when using const pointer to fixed size array

[Andrew Haley]

Aaron Rocha wrote:
> I am using :
> 
> $ gcc -dumpversion
> 4.2.4
> $ gcc -dumpmachine
> x86_64-linux-gnu
> 
> As expected, the following code does not generate any warnings when compiling with -Wall:
> 
> int main() {
> 
>    int number = 0;
> 
>    const int * const t = &number;
> 
>    return *t;
> }
> 
> However, this code does:
> 
> int main() {
> 
>    int array[9] = {0};
> 
>    const int (* const p)[9] = &array;
> 
>    return (*p)[0];
> }
> 
> $ gcc -Wall ./tst2.c 
> ./tst2.c: In function ‘main’:
> ./tst2.c:7: warning: initialization from incompatible pointer type
> 
> In order to eliminate this warning, I have to declare array as:
> 
> const int array[9];
> 
> Why is this the case though? In both examples, I am trying to use a const pointer to access a non-const variable for read-only purposes. Isn't this supposed to be OK?

You're really tying yourself in knots here.  The address of an array
is the address of its first member, so

int main() {

   int array[9] = {0};

   const int *p = array;

   return p[0];
}

Andrew.

Re: Warning when using const pointer to fixed size array

[Aaron Rocha]

> 
> You're really tying yourself in knots here.  The
> address of an array
> is the address of its first member, so
> 
> int main() {
> 
>    int array[9] = {0};
> 
>    const int *p = array;
> 
>    return p[0];
> }
> 
> Andrew.
> 

The advantage of declaring a pointer like I had mentioned in my original
posting is that I will get a compiler error if someone tries to give me a
buffer of a different size. Let's say you are only working
with fixed size buffers and you are expecting to get a pointer to one of
them. The prototype of your function could look like this:

void foo(const int * p, int plen);

However, in this case you will have to:

a) Verify that plen matches the fixed size you are expecting

b) Trust that the caller indeed gave you a buffer p with valid plen
   memory locations.

c) Problems will not be caught at compile time. Only at run-time.

This is ok if you are working with buffers that may vary in size. But if
your buffers have a fixed size, wouldn't it be better to do this?

void foo(const int (* p)[9]);

In this case, you are guaranteed that the caller is giving you a valid
buffer. Otherwise, you will get a compile error message which will help
you quickly detect a problem.

Do you understand now the motivation behind the question?

This is the reason why I am trying to do this:

int array[9];
const int (* p)[9] = &array;

But gcc complains that:

"warning: initialization from incompatible pointer type"

And I don't see why. Where in the standard it says that I am not allowed 
to do this? Should I log a bug against gcc so that I can get an explanation
from the developers themselves?

Thanks



      __________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

Re: Warning when using const pointer to fixed size array

[Sergei Organov]

Aaron Rocha <hxdg21@yahoo.com> writes:
[...]
> This is ok if you are working with buffers that may vary in size. But if
> your buffers have a fixed size, wouldn't it be better to do this?
>
> void foo(const int (* p)[9]);

$ cat array.c
void foo(const int (* p)[9]);
void boo(const int p[9]);
int main()
{
  int array[9];
  foo(&array);
  boo(array);
  return 0;
}
$ gcc -c -W -Wall array.c
array.c: In function ‘main’:
array.c:6: warning: passing argument 1 of ‘foo’ from incompatible pointer type
$

You see? Use the second, simpler declaration, and you are OK.

-- Sergei.

Re: Warning when using const pointer to fixed size array

[me22]

2009/12/1 Sergei Organov <osv@javad.com>:
>
> void boo(const int p[9]);
>
> You see? Use the second, simpler declaration, and you are OK.
>

But then p is a pointer, not an array.

Re: Warning when using const pointer to fixed size array

[Andrew Haley]

Aaron Rocha wrote:
>> You're really tying yourself in knots here.  The
>> address of an array
>> is the address of its first member, so
>>
>> int main() {
>>
>>    int array[9] = {0};
>>
>>    const int *p = array;
>>
>>    return p[0];
>> }

>
> The advantage of declaring a pointer like I had mentioned in my original
> posting is that I will get a compiler error if someone tries to give me a
> buffer of a different size. Let's say you are only working
> with fixed size buffers and you are expecting to get a pointer to one of
> them. The prototype of your function could look like this:
>
> void foo(const int * p, int plen);
>
> However, in this case you will have to:
>
> a) Verify that plen matches the fixed size you are expecting
>
> b) Trust that the caller indeed gave you a buffer p with valid plen
>    memory locations.
>
> c) Problems will not be caught at compile time. Only at run-time.
>
> This is ok if you are working with buffers that may vary in size. But if
> your buffers have a fixed size, wouldn't it be better to do this?
>
> void foo(const int (* p)[9]);
>
> In this case, you are guaranteed that the caller is giving you a valid
> buffer. Otherwise, you will get a compile error message which will help
> you quickly detect a problem.
>
> Do you understand now the motivation behind the question?
>
> This is the reason why I am trying to do this:
>
> int array[9];
> const int (* p)[9] = &array;
>
> But gcc complains that:
>
> "warning: initialization from incompatible pointer type"

Yes, and gcc is right.  The type of the array is array[9] of int,
whereas the type of your pointer is pointer to array[9] of const int.

> And I don't see why. Where in the standard it says that I am not
> allowed to do this?

6.7.3 Para 8: "If the specification of an array type includes any type
qualifiers, the element type is so qualified, not the array type.  For
two qualified types to be compatible, both shall have the identically
qualified version of a compatible type."

> Should I log a bug against gcc so that I can get an explanation
> from the developers themselves?

I am one.

Andrew.

Re: Warning when using const pointer to fixed size array

[Aaron Rocha]

> I am one.

Sweet! Then I got to the right person :)

> 
> 6.7.3 Para 8: "If the specification of an array type
> includes any type
> qualifiers, the element type is so qualified, not the array
> type.  For
> two qualified types to be compatible, both shall have the
> identically
> qualified version of a compatible type."

Thanks for the clarification, Andrew. This is all I needed to know. 

Apparently, the standard is slightly different for C++ because I don't 
get a warning in the same situation. This is the clarification I was 
seeking regarding the C standard.

Thanks a bunch




      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.

Re: Warning when using const pointer to fixed size array

[John (Eljay) Love-Jensen]

Hi Aaron,

> void foo(const int (* p)[9]);
> 
> In this case, you are guaranteed that the caller is giving you a valid
> buffer. Otherwise, you will get a compile error message which will help
> you quickly detect a problem.

I think...

In C, arrays degenerate into pointers at the drop of a hat.

These two kinds of pointers are compatible:
int* p;
int const* p;

The two kinds of pointers are compatible:
int** p;
int* const* p;

The two kinds of pointers are not compatible:
int** p;
int const** p;

Your situation is like the third case.  The const is not
two-levels-of-indirection compatible.

Anyone have ISO 9899 on hand to cite chapter & verse?

HTH,
--Eljay

Re: Warning when using const pointer to fixed size array

[John (Eljay) Love-Jensen]

> Anyone have ISO 9899 on hand to cite chapter & verse?

Andrew> 6.7.3 Para 8:

Thanks Andrew!

Sincerely,
--Eljay

Re: Warning when using const pointer to fixed size array

[Andrew Haley]

John (Eljay) Love-Jensen wrote:
> Hi Aaron,
> 
>> void foo(const int (* p)[9]);
>>
>> In this case, you are guaranteed that the caller is giving you a valid
>> buffer. Otherwise, you will get a compile error message which will help
>> you quickly detect a problem.
> 
> I think...
> 
> In C, arrays degenerate into pointers at the drop of a hat.
> 
> These two kinds of pointers are compatible:
> int* p;
> int const* p;
> 
> The two kinds of pointers are compatible:
> int** p;
> int* const* p;
> 
> The two kinds of pointers are not compatible:
> int** p;
> int const** p;
> 
> Your situation is like the third case.  The const is not
> two-levels-of-indirection compatible.
> 
> Anyone have ISO 9899 on hand to cite chapter & verse?

I just did.  :-)

Andrew.

Re: Warning when using const pointer to fixed size array

[Andrew Haley]

Aaron Rocha wrote:
>> I am one.
> 
> Sweet! Then I got to the right person :)
> 
>> 6.7.3 Para 8: "If the specification of an array type includes any
>> type qualifiers, the element type is so qualified, not the array
>> type.  For two qualified types to be compatible, both shall have
>> the identically qualified version of a compatible type."
> 
> Thanks for the clarification, Andrew. This is all I needed to know. 
> 
> Apparently, the standard is slightly different for C++ because I don't 
> get a warning in the same situation. This is the clarification I was 
> seeking regarding the C standard.

C++ uses very different language when talking about this:


3.9.2 Compound types

Pointers to cv-qualified and cv-unqualified versions (3.9.3) of
layout-compatible types shall have the same value representation and
alignment requirements (3.9).


3.9.3 CV-qualifiers

The cv-qualified or cv-unqualified versions of a type are distinct
types; however, they shall have the same representation and alignment
requirements 46)

46) The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values from
functions, and members of unions.


By which I understand that the same rules as C apply.  I think.
It's hard to tell...  :-)

Andrew.

Re: Warning when using const pointer to fixed size array

[Sergei Organov]

me22 <me22.ca@gmail.com> writes:
> 2009/12/1 Sergei Organov <osv@javad.com>:
>>
>> void boo(const int p[9]);
>>
>> You see? Use the second, simpler declaration, and you are OK.
>>
>
> But then p is a pointer, not an array.

But then in

void foo(const int (* p)[9]);

'p' is also a pointer, not an array.

Re: Warning when using const pointer to fixed size array

[me22]

2009/12/1 Sergei Organov <osv@javad.com>:
> me22 <me22.ca@gmail.com> writes:
>> 2009/12/1 Sergei Organov <osv@javad.com>:
>>>
>>> void boo(const int p[9]);
>>>
>>> You see? Use the second, simpler declaration, and you are OK.
>>>
>>
>> But then p is a pointer, not an array.
>
> But then in
>
> void foo(const int (* p)[9]);
>
> 'p' is also a pointer, not an array.
>

Sorry; You're of course right.

I should been less specific and more useful and said, "But then you
lose the size of the array".

I've seen such things used in C++ like this:

    template <typename T, size_t N>
    size_t array_length(T (&)[N]) { return N; }

In place of sizeof(p)/sizeof(*p), in order to get a compilation
failure if a pointer is accidentally passed.

Re: Warning when using const pointer to fixed size array

[Sergei Organov]

me22 <me22.ca@gmail.com> writes:
> 2009/12/1 Sergei Organov <osv@javad.com>:
>> me22 <me22.ca@gmail.com> writes:
>>> 2009/12/1 Sergei Organov <osv@javad.com>:
>>>>
>>>> void boo(const int p[9]);
>>>>
>>>> You see? Use the second, simpler declaration, and you are OK.
>>>>
>>>
>>> But then p is a pointer, not an array.
>>
>> But then in
>>
>> void foo(const int (* p)[9]);
>>
>> 'p' is also a pointer, not an array.
>>
>
> Sorry; You're of course right.
>
> I should been less specific and more useful and said, "But then you
> lose the size of the array".

Yeah, you are right, I was under impression that the

  void boo(const int p[9]);

declaration will prevent calling the boo() like this:

  int a[10];
  boo(a);

It does not.

-- Sergei.

Re: Warning when using const pointer to fixed size array

[Aaron Rocha]

It is indeed hard to tell. You did answer my question though (i.e., by pointing where in the C standard that operation was not allowed. I wasn't sure that was the case).

Thanks for taking the time to look into this, Andrew.

--- On Tue, 12/1/09, Andrew Haley <aph@redhat.com> wrote:

> From: Andrew Haley <aph@redhat.com>
> Subject: Re: Warning when using const pointer to fixed size array
> To: "Aaron Rocha" <hxdg21@yahoo.com>
> Cc: gcc-help@gcc.gnu.org
> Received: Tuesday, December 1, 2009, 9:22 AM
> Aaron Rocha wrote:
> >> I am one.
> > 
> > Sweet! Then I got to the right person :)
> > 
> >> 6.7.3 Para 8: "If the specification of an array
> type includes any
> >> type qualifiers, the element type is so qualified,
> not the array
> >> type.  For two qualified types to be
> compatible, both shall have
> >> the identically qualified version of a compatible
> type."
> > 
> > Thanks for the clarification, Andrew.. This is all I
> needed to know. 
> > 
> > Apparently, the standard is slightly different for C++
> because I don't 
> > get a warning in the same situation. This is the
> clarification I was 
> > seeking regarding the C standard.
> 
> C++ uses very different language when talking about this:
> 
> 
> 3.9.2 Compound types
> 
> Pointers to cv-qualified and cv-unqualified versions
> (3.9.3) of
> layout-compatible types shall have the same value
> representation and
> alignment requirements (3.9).
> 
> 
> 3.9.3 CV-qualifiers
> 
> The cv-qualified or cv-unqualified versions of a type are
> distinct
> types; however, they shall have the same representation and
> alignment
> requirements 46)
> 
> 46) The same representation and alignment requirements are
> meant to
> imply interchangeability as arguments to functions, return
> values from
> functions, and members of unions.
> 
> 
> By which I understand that the same rules as C apply. 
> I think.
> It's hard to tell...  :-)
> 
> Andrew.
> 


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

RE: One question about gcc fix_includes

[He Yunlong-B20256]

Hi, Andrew,

	Glad to hear that, however, in my environment, the header files
do exist, for example:

	
/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-3/powerpc-none-linu
x-gnuspe/powerpc-none-linux-gnuspe/libc/usr/include/features.h
	it contains:
	40	   _SVID_SOURCE         ISO C, POSIX, and SVID things.
	41	   _ATFILE_SOURCE       Additional *at interfaces.
	42	   _GNU_SOURCE          All of the above, plus GNU
extensions.

	However, in /usr/include/features.h, it contains following
lines:

	40	   _SVID_SOURCE         ISO C, POSIX, and SVID things.
   	41	   _GNU_SOURCE          All of the above, plus GNU
extensions. 

	In generated gcc-4.3.2/build-gcc/gcc/include-fixed/features.h,
following lines found: 
	1	/*  DO NOT EDIT THIS FILE.
 	2
	3	    It has been auto-edited by fixincludes from:
	4
	5	        "/usr/include/features.h"
	6
	7	    This had to be done to correct non-standard usages
in the
	8	    original, manufacturer supplied header file.  */

	49	   _SVID_SOURCE         ISO C, POSIX, and SVID things.
	50	   _GNU_SOURCE          All of the above, plus GNU
extensions.

	I didn't change any fix-includes related files,  so that's what
gcc compiling process does, is there anything wrong in my build process?

B.R.
Harry

-----Original Message-----
From: Andrew Haley [mailto:aph@redhat.com] 
Sent: Tuesday, December 01, 2009 5:34 PM
To: He Yunlong-B20256
Cc: gcc-help@gcc.gnu.org
Subject: Re: One question about gcc fix_includes

He Yunlong-B20256 wrote:

> 	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?

That doesn't sound right.  gcc is supposed to fixinclude the headers
from the C library for the target.  It's possible you failed to provide
them.

Andrew.

Re: One question about gcc fix_includes

[Andrew Haley]

He Yunlong-B20256 wrote:

> 
> 	Glad to hear that, however, in my environment, the header files
> do exist, for example:
> 
> 	
> /opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-3/powerpc-none-linu
> x-gnuspe/powerpc-none-linux-gnuspe/libc/usr/include/features.h
> 	it contains:
> 	40	   _SVID_SOURCE         ISO C, POSIX, and SVID things.
> 	41	   _ATFILE_SOURCE       Additional *at interfaces.
> 	42	   _GNU_SOURCE          All of the above, plus GNU
> extensions.
> 
> 	However, in /usr/include/features.h, it contains following
> lines:
> 
> 	40	   _SVID_SOURCE         ISO C, POSIX, and SVID things.
>    	41	   _GNU_SOURCE          All of the above, plus GNU
> extensions. 
> 
> 	In generated gcc-4.3.2/build-gcc/gcc/include-fixed/features.h,
> following lines found: 
> 	1	/*  DO NOT EDIT THIS FILE.
>  	2
> 	3	    It has been auto-edited by fixincludes from:
> 	4
> 	5	        "/usr/include/features.h"
> 	6
> 	7	    This had to be done to correct non-standard usages
> in the
> 	8	    original, manufacturer supplied header file.  */
> 
> 	49	   _SVID_SOURCE         ISO C, POSIX, and SVID things.
> 	50	   _GNU_SOURCE          All of the above, plus GNU
> extensions.
> 
> 	I didn't change any fix-includes related files,  so that's what
> gcc compiling process does, is there anything wrong in my build process?

You didn't tell me how you built gcc, so I cannot know.  However, I
suspect that gcc did not see find headers in your sysroot.  What does
the features.h in your target's C library look like?

Andrew.

Re: One question about gcc fix_includes

[Kai Ruottu]

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?

RE: One question about gcc fix_includes

[He Yunlong-B20256]

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?
> 
>