xref: /netbsd-src/external/gpl3/binutils.old/lib/libbfd/arch/hppa/bfdver.h (revision e992f068c547fd6e84b3f104dc2340adcc955732)
116dce513Schristos /* This file is automatically generated.  DO NOT EDIT! */
2*e992f068Schristos /* Generated from: NetBSD: mknative-binutils,v 1.14 2022/12/24 20:17:46 christos Exp  */
3ede78133Schristos /* Generated from: NetBSD: mknative.common,v 1.16 2018/04/15 15:13:37 christos Exp  */
416dce513Schristos 
5ede78133Schristos /* The date below is automatically updated every day by a bot.  During
6ede78133Schristos    development, we include the date in the tools' version strings
7ede78133Schristos    (visible in 'ld -v' etc.) because people build binutils from a
8ede78133Schristos    variety of sources - git, tarballs, distro sources - and we want
9ede78133Schristos    something that can easily identify the source they used when they
10ede78133Schristos    report bugs.  The bfd version plus date is usually good enough for
11ede78133Schristos    that purpose.
12ede78133Schristos 
13ede78133Schristos    During development, this date ends up in libbfd and libopcodes
14ede78133Schristos    sonames because people naturally expect shared libraries with the
15ede78133Schristos    same soname to have compatible ABIs.  We could bump the bfd version
16ede78133Schristos    on every ABI change, but that's just another thing contributors and
17ede78133Schristos    maintainers would need to remember.  Instead, it's much easier for
18ede78133Schristos    all if the soname contains the date.  This is not perfect but is
19ede78133Schristos    good enough.
20ede78133Schristos 
21ede78133Schristos    In releases, the date is not included in either version strings or
22ede78133Schristos    sonames.  */
23*e992f068Schristos #define BFD_VERSION_DATE 20220805
24*e992f068Schristos #define BFD_VERSION 239000000
25*e992f068Schristos #define BFD_VERSION_STRING  "(NetBSD Binutils nb1)" " " "2.39"
2616dce513Schristos #define REPORT_BUGS_TO "<http://www.NetBSD.org/support/send-pr.html>"
27