[Patch]: upgrade to automake 1.11.1

[Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

Hi,

automake 1.11 has a security issue and gnu.org sites don't allow to upload package that still use
automake 1.11.  I have regenerated files using 1.11.1

Ok to apply ?

Tristan.

bfd/
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1

bfd/doc
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1

binutils/
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in, aclocal.m4, doc/Makefile.in: Regenerate with
	automake 1.11.1

gas/
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in, aclocal.m4, doc/Makefile.in: Regenerate with
	automake 1.11.1

gprof/
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1

ld/
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1

opcodes/
2010-03-31  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1

Re: [Patch]: upgrade to automake 1.11.1

[Ralf Wildenhues]

Hello Tristan,

* Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
> automake 1.11 has a security issue and gnu.org sites don't allow to
> upload package that still use automake 1.11.

How unfortunate.  binutils don't contain nor use the 'make dist' rule
which contains the bug.  The Automake option 'no-dist' prevents the
rules to be present in the generated makefiles.

Why can gnu.org not grep for the presence of the rule instead?
That's the usual Autoconf-like approach, and distributions are
going to backport security fixes over upgrading versions, too.
Jim?

>  I have regenerated files using 1.11.1

I'd have preferred to avoid version churn between binutils and GCC,
at this GCC stage, for a purely administrative issue.

> Ok to apply ?

I can't approve or reject that.  Have you tested it?
(Not that I know of any incompatibilities.)

> bfd/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1
[...]

Cheers,
Ralf

Re: [Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

On Mar 31, 2010, at 10:27 AM, Ralf Wildenhues wrote:

> Hello Tristan,
> 
> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
>> automake 1.11 has a security issue and gnu.org sites don't allow to
>> upload package that still use automake 1.11.
> 
> How unfortunate.  binutils don't contain nor use the 'make dist' rule
> which contains the bug.  The Automake option 'no-dist' prevents the
> rules to be present in the generated makefiles.

Ah, interesting.

> Why can gnu.org not grep for the presence of the rule instead?
> That's the usual Autoconf-like approach, and distributions are
> going to backport security fixes over upgrading versions, too.
> Jim?
> 
>> I have regenerated files using 1.11.1
> 
> I'd have preferred to avoid version churn between binutils and GCC,
> at this GCC stage, for a purely administrative issue.

Why not updating GCC ?  Sooner or later we will have to update, before the next
binutils release.
Can you clarify briefly the 'administrative issue' ?

>> Ok to apply ?
> 
> I can't approve or reject that.  Have you tested it?
> (Not that I know of any incompatibilities.)

Yes, I rebuilt the tools.  Also binutils 2.20.1 was updated to automake 1.11.1.

Tristan.

Re: [Patch]: upgrade to automake 1.11.1

[Ralf Wildenhues]

* Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:34:15AM CEST:
> On Mar 31, 2010, at 10:27 AM, Ralf Wildenhues wrote:
> > * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
> >> I have regenerated files using 1.11.1
> > 
> > I'd have preferred to avoid version churn between binutils and GCC,
> > at this GCC stage, for a purely administrative issue.
> 
> Why not updating GCC ?

Because it is in Stage 4, and it doesn't use the 'dist' rule either.
Hmm, it contains it in some places as dead code though, where neither
'no-dist' nor 'cygnus' options are enabled.  Oh well.  Guess better to
upgrade src and GCC at the same time then.

> Can you clarify briefly the 'administrative issue' ?

I'd call gnu.org having a too-strict rule an administrative issue.

Re: [Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

On Mar 31, 2010, at 10:44 AM, Ralf Wildenhues wrote:

> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:34:15AM CEST:
>> On Mar 31, 2010, at 10:27 AM, Ralf Wildenhues wrote:
>>> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
>>>> I have regenerated files using 1.11.1
>>> 
>>> I'd have preferred to avoid version churn between binutils and GCC,
>>> at this GCC stage, for a purely administrative issue.
>> 
>> Why not updating GCC ?
> 
> Because it is in Stage 4, and it doesn't use the 'dist' rule either.
> Hmm, it contains it in some places as dead code though, where neither
> 'no-dist' nor 'cygnus' options are enabled.  Oh well.  Guess better to
> upgrade src and GCC at the same time then.

Ok.  Can you take care of the GCC update ?

>> Can you clarify briefly the 'administrative issue' ?
> 
> I'd call gnu.org having a too-strict rule an administrative issue.

Ah, understood.  I agree this is too-strict, and was surprise by this rule.  I don't know where it was
announced.

Cheers,
Tristan.

Re: [Patch]: upgrade to automake 1.11.1

[Jim Meyering]

Ralf Wildenhues wrote:
> Hello Tristan,
>
> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
>> automake 1.11 has a security issue and gnu.org sites don't allow to
>> upload package that still use automake 1.11.

Hi Tristan, Ralf,

> How unfortunate.  binutils don't contain nor use the 'make dist' rule
> which contains the bug.  The Automake option 'no-dist' prevents the
> rules to be present in the generated makefiles.
>
> Why can gnu.org not grep for the presence of the rule instead?
> That's the usual Autoconf-like approach, and distributions are
> going to backport security fixes over upgrading versions, too.
> Jim?

The upload check searches for the offending chmod command
which does something equivalent to chmod -R 777 ...
That is part of the distdir rule, so if no-dist doesn't
arrange to elide that rule, it'll still trigger the rejection.
But in a way, it's still legit, since an offending rule is still
being distributed, and while far-fetched, someone could
conceivably run "make distdir".

Note that while I suggested and reviewed the code to perform
that check, I cannot change it.  I don't even have access to the
official repo containing that code, afaik.
If you want to refine the check, we can check with GNU sysadmins.

Re: [Patch]: upgrade to automake 1.11.1

[Jim Meyering]

Ralf Wildenhues wrote:
> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:34:15AM CEST:
>> On Mar 31, 2010, at 10:27 AM, Ralf Wildenhues wrote:
>> > * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
>> >> I have regenerated files using 1.11.1
>> >
>> > I'd have preferred to avoid version churn between binutils and GCC,
>> > at this GCC stage, for a purely administrative issue.
>>
>> Why not updating GCC ?
>
> Because it is in Stage 4, and it doesn't use the 'dist' rule either.
> Hmm, it contains it in some places as dead code though, where neither
> 'no-dist' nor 'cygnus' options are enabled.  Oh well.  Guess better to
> upgrade src and GCC at the same time then.
>
>> Can you clarify briefly the 'administrative issue' ?
>
> I'd call gnu.org having a too-strict rule an administrative issue.

Distributing code built with unpatched automake is normally
serious enough that I feel the current upload-check is appropriate.
However, if there are more projects like binutils that use the no-dist
option, and they can demonstrate that upgrading is not feasible
(I'd be surprised), then it may well make sense to relax it to
accommodate them.

Hmm... I tried using no-dist, and the resulting Makefile
contains no distdir rule at all, so I can't see how it would
trigger the check.

Perhaps this is a feature new to automake-1.11a, and your 1.11
does not elide the distdir rule when no-dist is used.
Or you have a subdir-project which *does* have an offending
dist-related rule.

Re: [Patch]: upgrade to automake 1.11.1

[Joseph S. Myers]

On Wed, 31 Mar 2010, Jim Meyering wrote:

> The upload check searches for the offending chmod command
> which does something equivalent to chmod -R 777 ...

That sounds like it would break uploading new releases of GCC 4.3 and 4.4 
(using automake 1.9.6, and major upgrades are *certainly* inappropriate 
for release branches).  GCC does not use "make dist".  If you try "make 
dist" at toplevel in either GCC or src it will tell you so.

Checking for world-writable distributed directories might make sense (that 
would also require the GCC release branches to be changed, but that would 
be a safe change); it makes rather more sense than checking for what a 
user might hypothetically do themselves with "make dist".

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Patch]: upgrade to automake 1.11.1

[Ralf Wildenhues]

* Jim Meyering wrote on Wed, Mar 31, 2010 at 05:17:24PM CEST:
> Ralf Wildenhues wrote:
> > I'd call gnu.org having a too-strict rule an administrative issue.
> 
> Distributing code built with unpatched automake is normally
> serious enough that I feel the current upload-check is appropriate.
> However, if there are more projects like binutils that use the no-dist
> option, and they can demonstrate that upgrading is not feasible
> (I'd be surprised), then it may well make sense to relax it to
> accommodate them.

I guess upgrading old release branches could be a problem.  The upgrade
from 1.9.6 to 1.11 was nontrivial for binutils, and Autoconf would need
updating, too.  I guess if that's really necessary to do for GCC, then
I'd rather release an 1.9.7 with the security fix applied.

> Hmm... I tried using no-dist, and the resulting Makefile
> contains no distdir rule at all, so I can't see how it would
> trigger the check.

Oops.  gold/Makefile.am uses neither no-dist nor cygnus options.
Sorry about the false alarm then.

So, maybe the right thing to do for old GCC branches is to add no-dist
to all offending configure.ac/Makefile.am files.

> Perhaps this is a feature new to automake-1.11a, and your 1.11
> does not elide the distdir rule when no-dist is used.

no-dist is very old.

> Or you have a subdir-project which *does* have an offending
> dist-related rule.

Yep.

Tristan, you shouldn't have to update binutils to 1.11.1 with the patch
below, and even if you did already, the patch below is a useful size
reduction.  OK to commit?  (Tested by running 'make' and by inspection
of the Makefile.in diff.)

Thanks,
Ralf

Use Automake option no-dist in gold

gold/ChangeLog:
2010-03-31  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* Makefile.am (AUTOMAKE_OPTIONS): Add no-dist.
	* Makefile.in: Regenerate.

diff --git a/gold/Makefile.am b/gold/Makefile.am
index e0665e0..f50d7ff 100644
--- a/gold/Makefile.am
+++ b/gold/Makefile.am
@@ -1,6 +1,6 @@
 # Process this file with automake to generate Makefile.in
 
-AUTOMAKE_OPTIONS = foreign
+AUTOMAKE_OPTIONS = foreign no-dist
 
 SUBDIRS = po testsuite
 

Re: [Patch]: upgrade to automake 1.11.1

[Jim Meyering]

Joseph S. Myers wrote:
> On Wed, 31 Mar 2010, Jim Meyering wrote:
>> The upload check searches for the offending chmod command
>> which does something equivalent to chmod -R 777 ...
>
> That sounds like it would break uploading new releases of GCC 4.3 and 4.4
> (using automake 1.9.6, and major upgrades are *certainly* inappropriate
> for release branches).  GCC does not use "make dist".  If you try "make
> dist" at toplevel in either GCC or src it will tell you so.

The risk is relatively low (odds are low that someone will run a
distdir-using rule from a subdir while an attacker is prepared to strike),
but the cost of an exploit could be very high.  That is why the upload
guard checks all makefiles, and not just those at the top level.

> Checking for world-writable distributed directories might make sense (that

The net effect (world-writable dist dirs) is not the real risk.
The risk is that while the tarball is being created, the directories
being put into it are world writable, and so can potentially
be made to contain anything.  If you or anyone else then use the
result of that "make dist"-like rule in the wrong way (like untar
and run its configure), you lose.

> would also require the GCC release branches to be changed, but that would
> be a safe change); it makes rather more sense than checking for what a
> user might hypothetically do themselves with "make dist".

Ralf went to some pains to back-port the fix to multiple older versions
of automake, so you should be able to get by with your preferred version
plus that patch.

Re: [Patch]: upgrade to automake 1.11.1

[Joseph S. Myers]

On Wed, 31 Mar 2010, Jim Meyering wrote:

> > Checking for world-writable distributed directories might make sense (that
> 
> The net effect (world-writable dist dirs) is not the real risk.
> The risk is that while the tarball is being created, the directories
> being put into it are world writable, and so can potentially
> be made to contain anything.  If you or anyone else then use the

But checking for world-writable directories in the tarball seems like a 
more reliable way of determining whether the build of the tarball was 
exposed to the risk than checking for "make dist" rules that may be dead 
code for any package not using "make dist" to make its releases (while 
failing to check for other packaging scripts, such as that used by GCC, 
that also implement that former requirement of the GNU Coding Standards).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Patch]: upgrade to automake 1.11.1

[Ralf Wildenhues]

* Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:49:03AM CEST:
> On Mar 31, 2010, at 10:44 AM, Ralf Wildenhues wrote:
> > * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:34:15AM CEST:
> >> On Mar 31, 2010, at 10:27 AM, Ralf Wildenhues wrote:
> >>> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
> >>>> I have regenerated files using 1.11.1
> >>> 
> >>> I'd have preferred to avoid version churn between binutils and GCC,
> >>> at this GCC stage, for a purely administrative issue.
> >> 
> >> Why not updating GCC ?
> > 
> > Because it is in Stage 4, and it doesn't use the 'dist' rule either.
> > Hmm, it contains it in some places as dead code though, where neither
> > 'no-dist' nor 'cygnus' options are enabled.  Oh well.  Guess better to
> > upgrade src and GCC at the same time then.
> 
> Ok.  Can you take care of the GCC update ?

Done for trunk.

Cheers,
Ralf

Ping: [Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

On Apr 4, 2010, at 9:21 AM, Ralf Wildenhues wrote:

> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:49:03AM CEST:
>> On Mar 31, 2010, at 10:44 AM, Ralf Wildenhues wrote:
>>> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:34:15AM CEST:
>>>> On Mar 31, 2010, at 10:27 AM, Ralf Wildenhues wrote:
>>>>> * Tristan Gingold wrote on Wed, Mar 31, 2010 at 10:20:43AM CEST:
>>>>>> I have regenerated files using 1.11.1
>>>>> 
>>>>> I'd have preferred to avoid version churn between binutils and GCC,
>>>>> at this GCC stage, for a purely administrative issue.
>>>> 
>>>> Why not updating GCC ?
>>> 
>>> Because it is in Stage 4, and it doesn't use the 'dist' rule either.
>>> Hmm, it contains it in some places as dead code though, where neither
>>> 'no-dist' nor 'cygnus' options are enabled.  Oh well.  Guess better to
>>> upgrade src and GCC at the same time then.
>> 
>> Ok.  Can you take care of the GCC update ?
> 
> Done for trunk.

Thanks, so ping for this patch!

Tristan.

Re: [Patch]: upgrade to automake 1.11.1

[Ian Lance Taylor]

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> gold/ChangeLog:
> 2010-03-31  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
>
> 	* Makefile.am (AUTOMAKE_OPTIONS): Add no-dist.
> 	* Makefile.in: Regenerate.

This is OK.

Thanks.

Do you also need to change gold/testsuite/Makefile.am?  The
corresponding change is preapproved if appropriate.

Ian

Re: [Patch]: upgrade to automake 1.11.1

[Ralf Wildenhues]

* Ian Lance Taylor wrote on Tue, Apr 06, 2010 at 10:35:56PM CEST:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> 
> > gold/ChangeLog:
> > 2010-03-31  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
> >
> > 	* Makefile.am (AUTOMAKE_OPTIONS): Add no-dist.
> > 	* Makefile.in: Regenerate.
> 
> This is OK.
> 
> Thanks.
> 
> Do you also need to change gold/testsuite/Makefile.am?  The
> corresponding change is preapproved if appropriate.

Well, a per-Makefile.am setting only affects that directory; if you want
the setting to apply to all gold directories, we can use
  AM_INIT_AUTOMAKE([no-dist])

in configure.ac, that's cleaner than repeating.  OK instead?
(The problematic part of the 'make dist' code only happens in toplevel
Makefiles.)

Thanks,
Ralf

Re: [Patch]: upgrade to automake 1.11.1

[Ian Lance Taylor]

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> * Ian Lance Taylor wrote on Tue, Apr 06, 2010 at 10:35:56PM CEST:
>> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>> 
>> > gold/ChangeLog:
>> > 2010-03-31  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
>> >
>> > 	* Makefile.am (AUTOMAKE_OPTIONS): Add no-dist.
>> > 	* Makefile.in: Regenerate.
>> 
>> This is OK.
>> 
>> Thanks.
>> 
>> Do you also need to change gold/testsuite/Makefile.am?  The
>> corresponding change is preapproved if appropriate.
>
> Well, a per-Makefile.am setting only affects that directory; if you want
> the setting to apply to all gold directories, we can use
>   AM_INIT_AUTOMAKE([no-dist])
>
> in configure.ac, that's cleaner than repeating.  OK instead?
> (The problematic part of the 'make dist' code only happens in toplevel
> Makefiles.)

Either way is fine with me.  Whatever works.

Thanks.

Ian

Re: [Patch]: upgrade to automake 1.11.1

[Ralf Wildenhues]

* Ian Lance Taylor wrote on Wed, Apr 07, 2010 at 03:57:17PM CEST:
> Ralf Wildenhues writes:
> > Well, a per-Makefile.am setting only affects that directory; if you want
> > the setting to apply to all gold directories, we can use
> >   AM_INIT_AUTOMAKE([no-dist])
> >
> > in configure.ac, that's cleaner than repeating.  OK instead?
> > (The problematic part of the 'make dist' code only happens in toplevel
> > Makefiles.)
> 
> Either way is fine with me.  Whatever works.

OK.  I committed this now.

Thanks,
Ralf

2010-04-07  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* configure.ac (AM_INIT_AUTOMAKE): Add option no-dist.
	* configure: Regenerate.
	* Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

Index: configure.ac
===================================================================
RCS file: /cvs/src/src/gold/configure.ac,v
retrieving revision 1.54
diff -u -r1.54 configure.ac
--- configure.ac	6 Feb 2010 20:14:01 -0000	1.54
+++ configure.ac	7 Apr 2010 21:06:39 -0000
@@ -7,7 +7,7 @@
 
 AC_CANONICAL_TARGET
 
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([no-dist])
 
 AM_CONFIG_HEADER(config.h:config.in)
 

Ping: [Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

Hi,

now that gcc has switched to automake 1.11.1, could binutils also switch ?
(Still required to upload a release on gnu.org)

Tristan.

On Mar 31, 2010, at 10:20 AM, Tristan Gingold wrote:

> Hi,
> 
> automake 1.11 has a security issue and gnu.org sites don't allow to upload package that still use
> automake 1.11.  I have regenerated files using 1.11.1
> 
> Ok to apply ?
> 
> Tristan.
> 
> bfd/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1
> 
> bfd/doc
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in: Regenerate with automake 1.11.1
> 
> binutils/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4, doc/Makefile.in: Regenerate with
> 	automake 1.11.1
> 
> gas/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4, doc/Makefile.in: Regenerate with
> 	automake 1.11.1
> 
> gprof/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1
> 
> ld/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1
> 
> opcodes/
> 2010-03-31  Tristan Gingold  <gingold@adacore.com>
> 
> 	* Makefile.in, aclocal.m4: Regenerate with automake 1.11.1
> 
> 

Re: Ping: [Patch]: upgrade to automake 1.11.1

[Nick Clifton]

Hi Tristan,

> now that gcc has switched to automake 1.11.1, could binutils also switch ?

Yes - would you be good enough to make it so ?

Cheers
   Nick

Re: Ping: [Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

On May 6, 2010, at 4:14 PM, Nick Clifton wrote:

> Hi Tristan,
> 
>> now that gcc has switched to automake 1.11.1, could binutils also switch ?
> 
> Yes - would you be good enough to make it so ?

Sure, as I proposed this patch.

Tristan.

Re: Ping: [Patch]: upgrade to automake 1.11.1

[Tristan Gingold]

On May 6, 2010, at 4:14 PM, Nick Clifton wrote:

> Hi Tristan,
> 
>> now that gcc has switched to automake 1.11.1, could binutils also switch ?
> 
> Yes - would you be good enough to make it so ?

I have committed this change.

Thanks,
Tristan.

bfd/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.
	* aclocal.m4: Ditto.

bfd/doc/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.

binutils/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.
	* aclocal.m4: Ditto.
	* doc/Makefile.in: Ditto.

gas/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.
	* aclocal.m4: Ditto.
	* doc/Makefile.in: Ditto.

gprof/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.
	* aclocal.m4: Ditto.

ld/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.
	* aclocal.m4: Ditto.

opcodes/
2010-05-07  Tristan Gingold  <gingold@adacore.com>

	* Makefile.in: Regenerate with automake 1.11.1.
	* aclocal.m4: Ditto.