This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Sync libiberty with gcc upstream


On 05/16/2015 06:49 PM, Iain Buclaw wrote:
> Pretty much the only change here are recent dlang demangling patches
> I've been making upstream.  I notice there is a couple of changes with
> a configure and a Makefile too that seem to have gotten slipped
> through, unless I'm mistaken.
> 

It's better to look at the patches that made those changes as atomic
units.  They must have regenerated configure because something
configure depends on changed.  But what was that?  That's not
being included in your merge, AFAICS.

E.g., after your patches, if we regenerate libiberty's configure,
do we get the same configure, or are we perhaps missing syncing
top level and/or config/ patches?

> +2015-04-10  Jakub Jelinek  <jakub@redhat.com>
> +	    Iain Sandoe  <iain@codesourcery.com>
> +
> +	PR target/65351
> +	* configure: Regenerate.
> +
> +2015-04-07  Jakub Jelinek  <jakub@redhat.com>
> +	    Iain Sandoe  <iain@codesourcery.com>
> +
> +	PR target/65351
> +	* configure: Regenerate.
> +

... because I suspect not.  These above looked like dup entries, but it's
actually one regeneration for a config/picflag.m4 change, and another
regeneration for a config/mh-darwin change.  But I'm not seeing these
changes in our copy of config/.  I think we should sync that up as well.

The libiberty/Makefile.in change was done along with a top level change:

    2015-04-14  Max Ostapenko  <m.ostapenko@partner.samsung.com>

        * Makefile.tpl (EXTRA_HOST_EXPORTS): New variables.
        (EXTRA_BOOTSTRAP_FLAGS): Likewise.
        (check-[+module+]): Add EXTRA_HOST_EXPORTS and EXTRA_BOOTSTRAP_FLAGS.
        * Makefile.in: Regenerate.

        libiberty/
        * testsuite/Makefile.in (LIBCFLAGS): Add LDFLAGS.

so it would seem to me that we should pull in that top level change as well.

I recommend replaying the gcc commits into our tree, instead of
syncing some of the files while missing others.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]