[00/24] Sync shared build infrastructure with binutils-gdb

  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/CAMe9rOqFSOSM5Sw5SBMiy20rdgRJkftUXdw=yKEXHvDMUtykdQ@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ć (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 >= 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="/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
  

On Mon, Aug 7, 2023 at 7:19 AM Arsen Arsenović via Gcc-patches
<gcc-patches@gcc.gnu.org> 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/CAMe9rOqFSOSM5Sw5SBMiy20rdgRJkftUXdw=yKEXHvDMUtykdQ@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ć (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 >= 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="/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?
  

Eric Gallager <egall@gwmail.gwu.edu> writes:

> 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?

Yes.  Libtool was forked over a decade ago.  My next project is syncing
upstream and us back up.  Unsure about pkg.m4.
  

On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote:

> Yes.  Libtool was forked over a decade ago.  My next project is syncing
> upstream and us back up.  Unsure about pkg.m4.

Note as per previous discussions that libtool commit 
3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting in GCC when 
updating libtool because of incompatible usage of --with-sysroot.  
Reportedly libtool is based on upstream commit 
2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622 (with *many* local changes, some 
of which may not be present upstream).
  

Hi Joseph

> On 8 Aug 2023, at 20:41, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote:
> 
>> Yes.  Libtool was forked over a decade ago.  My next project is syncing
>> upstream and us back up.  Unsure about pkg.m4.
> 
> Note as per previous discussions that libtool commit 
> 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting in GCC when 
> updating libtool because of incompatible usage of --with-sysroot.

Can you identify the consequence(s) of the difference?

(At present Darwin relies on configuring —with-sysroot to reference the system SDKs, since
 there are no longer any headers installed in / on Darwin hosts)

FWIW, we (FX and I) had started collating some of the Darwin libtool changes, (FX has posted one
upstream aready IIRC) since we also want to land the necessary support for @rpath.

> Reportedly libtool is based on upstream commit 
> 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622

I wonder if this will help track divergence.

> (with *many* local changes, some of which may not be present upstream).

maybe  s/some/most/ ? .. 

The other issue is that we might have changes that make sense local to GCC, but are not
really applicable more widely,

Iain


> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com
  

Joseph Myers <joseph@codesourcery.com> writes:

> On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote:
>
>> Yes.  Libtool was forked over a decade ago.  My next project is syncing
>> upstream and us back up.  Unsure about pkg.m4.
>
> Note as per previous discussions that libtool commit 
> 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting in GCC when 
> updating libtool because of incompatible usage of --with-sysroot.

I wanted to, somehow, coalesce the two back together, so that both are
available.  Presumably, this means adding an option to libtool to accept
host-sysroot or such, but I haven't done too much looking into this.

Is my interpretation of the issue correct?  (i.e. GCC uses sysroot to
mean *target* sysroot rather than host sysroot)

> Reportedly libtool is based on upstream commit 
> 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622 (with *many* local changes, some 
> of which may not be present upstream).

Thanks, sharing that base will save me a good amount of time.

Have a lovely night.
  

On Wed, 9 Aug 2023, Arsen Arsenović via Gcc-patches wrote:

> Joseph Myers <joseph@codesourcery.com> writes:
> 
> > On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote:
> >
> >> Yes.  Libtool was forked over a decade ago.  My next project is syncing
> >> upstream and us back up.  Unsure about pkg.m4.
> >
> > Note as per previous discussions that libtool commit 
> > 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting in GCC when 
> > updating libtool because of incompatible usage of --with-sysroot.
> 
> I wanted to, somehow, coalesce the two back together, so that both are
> available.  Presumably, this means adding an option to libtool to accept
> host-sysroot or such, but I haven't done too much looking into this.
> 
> Is my interpretation of the issue correct?  (i.e. GCC uses sysroot to
> mean *target* sysroot rather than host sysroot)

GCC's sysroot is a sysroot containing target headers and libraries, yes.  
Also note:

* The --with-sysroot directory is the directory that would be used by GCC 
if installed in the configured --prefix (relocated if GCC ends up running 
from a different prefix).  At build time, --with-build-sysroot takes 
precedence.

* The --with-sysroot directory (and likewise the --with-build-sysroot 
directory or any directory specified with --sysroot= passed to GCC 
programs) may sometimes contain multiple sysroots in subdirectories; that 
directory gets combined with a suffix from SYSROOT_SUFFIX_SPEC to 
determine the actual subdirectory for the current multilib, within which 
there are subdirectories such as usr/include or usr/lib.