On Tue, Jan 5, 2021 at 5:27 AM Christian Biesinger
wrote:
>
> On Fri, Jan 1, 2021 at 1:07 AM H.J. Lu via Gdb-patches
> wrote:
> >
> > On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers
> > wrote:
> > >
> > > On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote:
> > >
> > > > Work around what appears
On Fri, Jan 1, 2021 at 1:07 AM H.J. Lu via Gdb-patches
wrote:
>
> On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers wrote:
> >
> > On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote:
> >
> > > Work around what appears to be a GNU make bug handling MAKEFLAGS
> > > values defined in terms of make
On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers wrote:
>
> On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote:
>
> > Work around what appears to be a GNU make bug handling MAKEFLAGS
> > values defined in terms of make variables, as is the case for CC and
> > friends when we are called from the top
On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote:
> Work around what appears to be a GNU make bug handling MAKEFLAGS
> values defined in terms of make variables, as is the case for CC and
> friends when we are called from the top level Makefile.
This description, and the comment in Makefile.am
Work around what appears to be a GNU make bug handling MAKEFLAGS
values defined in terms of make variables, as is the case for CC and
friends when we are called from the top level Makefile.
* Makefile.am (AM_MAKEFLAGS): New.
* Makefile.in: Regenerated.
---
gnulib/Makefile.am | 39
