1c236fd95Schristos /* 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 */ 3d410c4eaSchristos /* Generated from: NetBSD: mknative.common,v 1.16 2018/04/15 15:13:37 christos Exp */ 4c236fd95Schristos 5d410c4eaSchristos /* The date below is automatically updated every day by a bot. During 6d410c4eaSchristos development, we include the date in the tools' version strings 7d410c4eaSchristos (visible in 'ld -v' etc.) because people build binutils from a 8d410c4eaSchristos variety of sources - git, tarballs, distro sources - and we want 9d410c4eaSchristos something that can easily identify the source they used when they 10d410c4eaSchristos report bugs. The bfd version plus date is usually good enough for 11d410c4eaSchristos that purpose. 12d410c4eaSchristos 13d410c4eaSchristos During development, this date ends up in libbfd and libopcodes 14d410c4eaSchristos sonames because people naturally expect shared libraries with the 15d410c4eaSchristos same soname to have compatible ABIs. We could bump the bfd version 16d410c4eaSchristos on every ABI change, but that's just another thing contributors and 17d410c4eaSchristos maintainers would need to remember. Instead, it's much easier for 18d410c4eaSchristos all if the soname contains the date. This is not perfect but is 19d410c4eaSchristos good enough. 20d410c4eaSchristos 21d410c4eaSchristos In releases, the date is not included in either version strings or 22d410c4eaSchristos 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" 26d16b7486Schristos #define REPORT_BUGS_TO "<https://sourceware.org/bugzilla/>" 27