[avr-libc-dev] Re: [avr-gcc-list] Find problem with gcc patching libc

[Andy H]

We seem to be both using 4.4 head and same configuration switches. 
Though different directories perhaps.

I have just noted that stdio.h in 1.6.2 is version 1.29 - where Mike is 
using 1.30. So I assume he is using HEAD version of libc??

I will thus check this version to see if it triggers problem.

I started at almost same time I added AVR target test. Which failed 
because of this issue. However, I was able to see same problem just 
before that on some other test.
Any tests with stdio.h will thus fail (on Mike's setup)

I think changes fixincludes are making are somewhat logical. Maybe 
Cygwin and Debian are wrong?

I am not sure what determines if file is fixed or not. The gcc code 
looks for missing functions and adds missing definitions. But what 
causes that to happen (or not) is a mystery to me.
Debian shows fixing messages for files prior to test. Cygwin does not. 
Just to confuse the issue!


Andy


Weddington, Eric wrote:
>  
>
>   
> > -----Original Message-----
> > From: 
> > address@hidden 
> > [mailto:address@hidden
> > org] On Behalf Of Andy H
> > Sent: Saturday, June 07, 2008 9:26 AM
> > To: Mike Stein; address@hidden; address@hidden
> > Subject: [avr-gcc-list] Find problem with gcc patching libc 
> >
> > I was looking for cause of problem with Mike Steins tests 
> > setup, where 
> > stdio.h gets patched by gcc.
> > This defines unused file functions but assume fpos_t is 
> > defined. Thus we 
> > get compilation failures.
> >
> > My cygwin and Debian linux setups dont have this problem.
> >
> > I have rebuilt my Debian setup with clean binutils, gcc and 
> > libc today 
> > from scratch so I now have 1.6.2 libc (same as Mike)
> >
> > Despite this  I cannot replicate problem at all.  Any ideas?
> >
> > I am re-running gcc testsuite and hopefully the result will 
> > be the same 
> > as 1.6.1 (or better)!
> >
> > Mike, you may want to try clean build. This problem only occurred 
> > recently, and was not connected to any patches.
> >     
>
> Since this is GCC's fixincludes that is doing the patching (I assume),
> then what version of GCC are you using, Mike, that is causing the
> problem? Andy, what version of GCC are you using that is NOT doing the
> patching?
>