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