xref: /netbsd-src/external/gpl3/gdb/lib/libbfd/arch/arm/bfdver.h (revision 22ebeae4b2252475e0ebe332f69734639cb946ea)
1cfa2879dSchristos /* This file is automatically generated.  DO NOT EDIT! */
2*22ebeae4Schristos /* Generated from: NetBSD: mknative-gdb,v 1.17 2024/08/18 03:47:55 rin Exp  */
33a781464Schristos /* Generated from: NetBSD: mknative.common,v 1.16 2018/04/15 15:13:37 christos Exp  */
4cfa2879dSchristos 
53a781464Schristos /* The date below is automatically updated every day by a bot.  During
63a781464Schristos    development, we include the date in the tools' version strings
73a781464Schristos    (visible in 'ld -v' etc.) because people build binutils from a
83a781464Schristos    variety of sources - git, tarballs, distro sources - and we want
93a781464Schristos    something that can easily identify the source they used when they
103a781464Schristos    report bugs.  The bfd version plus date is usually good enough for
113a781464Schristos    that purpose.
123a781464Schristos 
133a781464Schristos    During development, this date ends up in libbfd and libopcodes
143a781464Schristos    sonames because people naturally expect shared libraries with the
153a781464Schristos    same soname to have compatible ABIs.  We could bump the bfd version
163a781464Schristos    on every ABI change, but that's just another thing contributors and
173a781464Schristos    maintainers would need to remember.  Instead, it's much easier for
183a781464Schristos    all if the soname contains the date.  This is not perfect but is
193a781464Schristos    good enough.
203a781464Schristos 
213a781464Schristos    In releases, the date is not included in either version strings or
223a781464Schristos    sonames.  */
23*22ebeae4Schristos #define BFD_VERSION_DATE 20240707
24*22ebeae4Schristos #define BFD_VERSION 242500000
25*22ebeae4Schristos #define BFD_VERSION_STRING  "(GNU Binutils) " "2.42.50"
26901e7e84Schristos #define REPORT_BUGS_TO "<https://sourceware.org/bugzilla/>"
27