From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by sourceware.org (Postfix) with ESMTPS id D92B03858D28 for ; Mon, 7 Aug 2023 19:54:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D92B03858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwmail.gwu.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwmail.gwu.edu Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-44779e3e394so2066720137.0 for ; Mon, 07 Aug 2023 12:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gwmail.gwu.edu; s=google; t=1691438074; x=1692042874; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EqPvEespbHvA7pqAHFisd7q71HvNMg6L3b3bMFNK5z8=; b=FGLbria3jz/+IdQpBNZGFVxx534+KwjXFyUGNBJsO0RHkXQorB4S4lsrfcs9IVntlB 2CKaUqOKKPBP1HyKNwDVSkVfORY/35gl1JIXsIl5Ayu0/aVb7ILQCvr+IbNkqitfDspt RBnIOZhrb3e4FgHqtdr0a+bpfn5B15Z30zegsG/gCPdNyvTVuYmzFl4a8Z/7TFtgu/VF riHche28jN676aamwqiUZZZUg6AEbpzemFsQk6TFVelKVt5d0s1M/TfQpPp7emwBiLT5 WNCRxDbC/badlXPoY6e/64mo7iy0vLTfTPd8S7zYiTgi36rc64CxEsPFjJzPWU+IlYzY b8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691438074; x=1692042874; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EqPvEespbHvA7pqAHFisd7q71HvNMg6L3b3bMFNK5z8=; b=TqjKDHk45Ydb1O++UsxaHYJm2RyqieMljcjLiyCdWdCqlaemO5hddYVDiZzd2dPqsM DCLdG4OYeeRNoYVvcGinnqguyM25uqemFG04/AKJ7WthXsbQ75tuJdJt4jMRNeXRCmFz JAk/4XtsJxkrovpGSAZYkMqV8TNUTf4Q9SZx2X8eSCNnjz2B2dYVt4JvYCcAuiXgRF5z xPNBcBZaFoWfJRnc96OTseLBG8YahsLvAAnc0/jagBdjsosiNkkIX5JCL2mhPQD9Dpp6 G17ssZvqtvmiV0oUCJsbI7ur7qVa/+BmgdMw8GifA2n3Sif+O1Hw2e1MmouPdy+DTvtP Fv3A== X-Gm-Message-State: AOJu0YxUhqjzFFB+CxKgxFFezINwyKMOU3ZF4LREvAqprh6t+Gb8Y9Bv BmP/bmzj4xoAxXPScX5cSw9MVwGEkB4xUGsPqckkpw== X-Google-Smtp-Source: AGHT+IEEn2bPrM+Al374eWVQoQq0i7fqLLTxHzj5l5CUq7UTZr1eEtpfXI+lRnKdekBNPOLqTGeAMUW3TsvPUs5tDNo= X-Received: by 2002:a67:fd54:0:b0:447:69cc:959c with SMTP id g20-20020a67fd54000000b0044769cc959cmr5357175vsr.6.1691438074082; Mon, 07 Aug 2023 12:54:34 -0700 (PDT) MIME-Version: 1.0 References: <20230807105935.2098236-1-arsen@aarsen.me> In-Reply-To: <20230807105935.2098236-1-arsen@aarsen.me> From: Eric Gallager Date: Mon, 7 Aug 2023 15:54:22 -0400 Message-ID: Subject: Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb To: =?UTF-8?Q?Arsen_Arsenovi=C4=87?= Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Aug 7, 2023 at 7:19=E2=80=AFAM Arsen Arsenovi=C4=87 via Gcc-patches wrote: > > Hello, > > This patch set, combined with a sibling patch set sent on the binutils > and GDB MLs, bring up the shared infrastructure between the two projects > in sync again. > > It largely consists of cherry-picks from various people which have been > reviewed and accepted on the binutils-gdb side, as well as a couple of > patches for differences that seemed to get lost during the > pick-and-regenerate process, though I've had to reformat quite a few > commits so that they match what the changelog verifier expects. > > Some of these commits were previously applied and then reverted, namely > "Check if AR works with --plugin and rc", but the reversion reason[1] > seems to be no longer valid as of requiring Binutils 2.35 for LTO > anyway. > > In addition, I'm not entirely certain that the handling of the removed > targets I re-added is correct, nor what their status in binutils and gdb > is, so feedback is welcome there. > > During this process, it appears that I overlooked passing -x to > cherry-pick, so the paper trail got lost. If needed, I can hack > together some code to associate commits based on subjects with their > pair in the other repository, and amend the commits with these > references added. > > These patches ignore the intl/ directory, as I plan to follow up this > patchset with one that can be cleanly applied to both trees which gets > rid of the intl/ directory in favor of out-of-tree gettext (ISL, GMP, et > al. style). > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > > OK for master? > > Thanks in advance, have a lovely day. > > [1]: https://inbox.sourceware.org/gcc-patches/CAMe9rOqFSOSM5Sw5SBMiy20rdg= RJkftUXdw=3DyKEXHvDMUtykdQ@mail.gmail.com/ > > Alan Modra (4): > PR29961, plugin-api.h: "Could not detect architecture endianess" > gcc-4.5 build fixes > egrep in binutils > PR27116, Spelling errors found by Debian style checker > > Alexander von Gluck IV (1): > Add support for the haiku operating system > > Arsen Arsenovi=C4=87 (3): > toplevel: Substitute GDCFLAGS instead of using CFLAGS > toplevel: Recover tilegx/tilepro targets > configure: reinstate 32b PA-RISC HP-UX target in toplevel > > Christophe Lyon (1): > configure: require libzstd >=3D 1.4.0 > > Fangrui Song (1): > binutils, gdb: support zstd compressed debug sections > > H.J. Lu (4): > Sync with binutils: GCC: Pass --plugin to AR and RANLIB > GCC: Check if AR works with --plugin and rc > PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works > PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works > > Indu Bhagat (2): > bfd: linker: merge .sframe sections > toplevel: Makefile.def: add install-strip dependency on libsframe > > John Ericson (1): > Deprecate a.out support for NetBSD targets. > > Luis Machado (1): > Disable year 2038 support on 32-bit hosts by default > > Martin Liska (1): > add --enable-default-compressed-debug-sections-algorithm configure > option > > Nick Alcock (3): > libtool.m4: fix nm BSD flag detection > libtool.m4: fix the NM=3D"/nm/over/here -B/option/with/path" case > libtool.m4: augment symcode for Solaris 11 > > Simon Marchi (1): > Pass PKG_CONFIG_PATH down from top-level Makefile > > Vladimir Mezentsev (1): > gprofng: a new GNU profiler > > Makefile.def | 18 ++ > Makefile.in | 517 ++++++++++++++++++++++++++++++++++++- > Makefile.tpl | 10 +- > config/gcc-plugin.m4 | 40 +++ > config/lib-ld.m4 | 8 +- > config/override.m4 | 2 +- > config/picflag.m4 | 4 +- > config/pkg.m4 | 8 + > config/zstd.m4 | 23 ++ > configure | 224 +++++++++++++++- > configure.ac | 74 +++++- > fixincludes/configure | 3 +- > gcc/configure | 140 ++++++---- > include/collectorAPI.h | 73 ++++++ > include/libcollector.h | 89 +++++++ > include/libfcollector.h | 42 +++ > include/plugin-api.h | 49 ++-- > include/xtensa-dynconfig.h | 2 - > intl/configure | 4 +- > libada/configure | 4 +- > libatomic/configure | 130 ++++++---- > libbacktrace/configure | 130 ++++++---- > libcc1/configure | 132 ++++++---- > libcpp/configure | 4 +- > libffi/configure | 132 ++++++---- > libgcc/configure | 6 +- > libgfortran/configure | 132 ++++++---- > libgm2/configure | 132 ++++++---- > libgomp/configure | 132 ++++++---- > libiberty/Makefile.in | 5 +- > libiberty/aclocal.m4 | 1 + > libiberty/configure | 144 ++++++++++- > libiberty/configure.ac | 12 + > libitm/configure | 132 ++++++---- > libobjc/configure | 130 ++++++---- > libphobos/configure | 130 ++++++---- > libquadmath/configure | 130 ++++++---- > libsanitizer/configure | 132 ++++++---- > libssp/configure | 130 ++++++---- > libstdc++-v3/configure | 148 +++++++---- > libtool.m4 | 130 ++++++---- > libvtv/configure | 132 ++++++---- > lto-plugin/configure | 130 ++++++---- > zlib/configure | 130 ++++++---- > 44 files changed, 2924 insertions(+), 956 deletions(-) > create mode 100644 config/zstd.m4 > create mode 100644 include/collectorAPI.h > create mode 100644 include/libcollector.h > create mode 100644 include/libfcollector.h > > -- > 2.41.0 > Hi, with the updates to libtool.m4 and pkg.m4, those files originally come from upstream libtool and pkg-config, correct? Won't patching GCC's local copies make re-syncing them with upstream libtool/pkg-config more difficult, or have these patches already been sent there, too? Also, when updating .m4 files, aren't you supposed to increment the serial number that they have near the top, too?