From: Pedro Alves Date: Fri, 22 Sep 2017 13:57:52 +0000 (+0100) Subject: bfd/version.h: Add rationale for BFD_VERSION_DATE X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=b877d21f34211915953487d68a07697f4cb4f771;p=binutils-gdb.git bfd/version.h: Add rationale for BFD_VERSION_DATE bfd/ChangeLog: 2017-09-22 Pedro Alves Alan Modra * version.h: Add comment. --- diff --git a/bfd/ChangeLog b/bfd/ChangeLog index ebefab38f5d..46643eb31da 100644 --- a/bfd/ChangeLog +++ b/bfd/ChangeLog @@ -1,3 +1,8 @@ +2017-09-22 Pedro Alves + Alan Modra + + * version.h: Add comment. + 2017-09-21 Andreas Arnez * elf.c (elfcore_grok_note): For the cases NT_S390_GS_CB and diff --git a/bfd/version.h b/bfd/version.h index 9e389e90389..162a820e891 100644 --- a/bfd/version.h +++ b/bfd/version.h @@ -1,3 +1,21 @@ +/* The date below is automatically updated every day by a bot. During + development, we include the date in the tools' version strings + (visible in 'ld -v' etc.) because people build binutils from a + variety of sources - git, tarballs, distro sources - and we want + something that can easily identify the source they used when they + report bugs. The bfd version plus date is usually good enough for + that purpose. + + During development, this date ends up in libbfd and libopcodes + sonames because people naturally expect shared libraries with the + same soname to have compatible ABIs. We could bump the bfd version + on every ABI change, but that's just another thing contributors and + maintainers would need to remember. Instead, it's much easier for + all if the soname contains the date. This is not perfect but is + good enough. + + In releases, the date is not included in either version strings or + sonames. */ #define BFD_VERSION_DATE 20170922 #define BFD_VERSION @bfd_version@ #define BFD_VERSION_STRING @bfd_version_package@ @bfd_version_string@