[top-level] Do proper target tool checks for readelf

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 one.  Right now, this seems to happen for the "main" newlib
build but doesn't happen for a multilib variant newlib build (e.g. in an
x86_64-foo config, build/x86_64-foo/newlib/... uses a target readelf but
build/x86_64-foo/32/newlib/... doesn't find one and so uses unadorned
"readelf", which might not exist on the build host in a cross situation).

Frankly I couldn't entirely tell which of all these magic spots were the
ones necessary to get the multilib newlib build to do the right thing.  But
it makes sense that the treatment of readelf be uniformly analogous to the
treatment of objdump, so I did that everywhere I found it.

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 were committed directly to src/.  I'm
able to commit (after approval) to src/ CVS, but not to GCC.

Ok for src/ trunk, or should somebody be putting this into GCC first?

I've omitted the generated files from the patch, but of course would
include them in a commit.


Thanks,
Roland

2011-11-02  Roland McGrath  <mcgrathr@google.com>

	* configure.ac: Add tool checks for READELF and READELF_FOR_TARGET.
	* configure: Rebuild.
	* Makefile.def (flags_to_pass): Add READELF_FOR_TARGET.
	* Makefile.tpl (READELF, READELF_FOR_TARGET): New variables.
	(HOST_EXPORTS): Add READELF, READELF_FOR_TARGET.
	(BASE_FLAGS_TO_PASS): Add READELF_FOR_TARGET.
	(BASE_TARGET_EXPORTS, EXTRA_HOST_FLAGS, EXTRA_TARGET_FLAGS):
	Add READELF.
	* Makefile.in: Rebuild.

Roland McGrath <mcgrathr@google.com> 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 were committed directly to src/.  I'm
> able to commit (after approval) to src/ CVS, but not to GCC.

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 for src/ trunk, or should somebody be putting this into GCC first?

So, yes, should probably go into gcc first.

Ian

On Wed, Nov 2, 2011 at 8:32 PM, Ian Lance Taylor <iant@google.com> 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 should somebody be putting this into GCC first?
>
> So, yes, should probably go into gcc first.

Ok.  Would you like to commit it for me, then?  I can take care of the src/
merge myself if you prefer.


Thanks,
Roland

Roland McGrath <mcgrathr@google.com> writes:

> On Wed, Nov 2, 2011 at 8:32 PM, Ian Lance Taylor <iant@google.com> 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 should somebody be putting this into GCC first?
>>
>> So, yes, should probably go into gcc first.
>
> Ok.  Would you like to commit it for me, then?  I can take care of the src/
> merge myself if you prefer.

Ideally I'd like to see a build maintainer approve it.  Perhaps I missed
that.

Ian

On Thu, Nov 3, 2011 at 10:39 AM, Ian Lance Taylor <iant@google.com> 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 "..." is "but they should be aware that they need to be kept in
sync with their counterparts in the GCC repository," I've now looked at
gcc/MAINTAINERS and see that it has a category "build machinery (*.in)"
that you are not in.  (You are in its "global reviewers" category, which
the wording there suggests is in fact sufficient.  But I certainly can't
argue with wanting to hear from one of the build maintainers, though I do
hope they respond soon.  That said, it seems hard to imagine that my change
would be objectionable.)


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:55 AM, DJ Delorie <dj@redhat.com> 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

On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath <mcgrathr@google.com> wrote:
> On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie <dj@redhat.com> 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.

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.)


Thanks,
Roland

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