> Ping. Anybody going to do this commit for me? (If insteaed someone would
> like to add me to the gcc group so I can do "write after approval", that
> would be fine too.)
Done.
On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath wrote:
> On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie wrote:
>> The patch looks OK to me.
>
> Thanks! As I'm still not a GCC committer, someone please check it in for me.
> If people would like me to handle the merge over to src/ myself, I'd be
> gl
On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie wrote:
> The patch looks OK to me.
Thanks! As I'm still not a GCC committer, someone please check it in for me.
If people would like me to handle the merge over to src/ myself, I'd be
glad to do that step.
Thanks,
Roland
> Ideally I'd like to see a build maintainer approve it. Perhaps I missed
> that.
I've got my usual paranoia about command line lengths being stressed,
but I suspect we're already way past the limits on the ones that will
actually fail.
The patch looks OK to me.
On Thu, Nov 3, 2011 at 10:39 AM, Ian Lance Taylor wrote:
> Ideally I'd like to see a build maintainer approve it. Perhaps I missed
> that.
Ah. The src/MAINTAINERS file says, "Any global maintainer can approve
changes to these files, ...", which in that context I think includes you.
But since ".
Roland McGrath writes:
> On Wed, Nov 2, 2011 at 8:32 PM, Ian Lance Taylor wrote:
>> The top level is not automatically merged between gcc and src. However,
>> people are expected to merge manually. Normally gcc is considered to be
>> the master.
>
> Ok. src/MAINTAINERS could be clearer about
On Wed, Nov 2, 2011 at 8:32 PM, Ian Lance Taylor wrote:
> The top level is not automatically merged between gcc and src. However,
> people are expected to merge manually. Normally gcc is considered to be
> the master.
Ok. src/MAINTAINERS could be clearer about that.
>> Ok for src/ trunk, or s
Roland McGrath writes:
> MAINTAINERS doesn't make it entirely clear what the procedure really is for
> touching these files. Looking at src/ChangeLog I see both what appear to
> be instances where changes were first committed to GCC and then merged over
> to src/, and instances where changes wer
newlib has a configure check that works by running readelf on a target
binary. While a native readelf is generally pretty generic and
cross-friendly, it's possible for a build host not to have any readelf at
all. It's clearly the right thing that configure use a target readelf tool
if there is on
