aboutsummaryrefslogtreecommitdiff
path: root/gdb/maint.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2013-07-01 11:14:42 +0000
committerPedro Alves <palves@redhat.com>2013-07-01 11:14:42 +0000
commit3574124b5f33fb080dfe11d4a98475a991e6fb25 (patch)
treed93b4b594f1ea61ec181d1f5fea0ea98c7329d03 /gdb/maint.c
parent702dc4fd25277e0b3206af531c59cea4fbf58be4 (diff)
downloadgdb-3574124b5f33fb080dfe11d4a98475a991e6fb25.zip
gdb-3574124b5f33fb080dfe11d4a98475a991e6fb25.tar.gz
gdb-3574124b5f33fb080dfe11d4a98475a991e6fb25.tar.bz2
Reimport gnulib from scratch.
Moving aside gnulib/import/, and re-running our gnulib/update-gnulib.sh script, surprisingly, one gets a different result compared to what's in the tree. This is with pristine FSF autoconf and FSF automake, at the versions required by update-gnulib.sh. However, if one just runs the update-gnulib.sh scripts against the _existing_ tree, then nothing changes... I suspect gnulib-tool's merge logic might be preserving some things by design. This gets rid of cruft that might have accumulated over gnulib updates. onceonly.m4 seems to fit in that category. gdb/ 2013-07-01 Pedro Alves <palves@redhat.com> Reimport gnulib from scratch. * gnulib/Makefile.in (aclocal_m4_deps): Remove reference to import/m4/onceonly.m4. * gnulib/aclocal.m4: Renegerate. * gnulib/config.in: Renegerate. * gnulib/configure: Renegerate. * gnulib/import/Makefile.in: Renegerate. * gnulib/import/extra/update-copyright: Renegerate. * gnulib/import/m4/onceonly.m4: Delete.
Diffstat (limited to 'gdb/maint.c')
0 files changed, 0 insertions, 0 deletions