As was pointed out on the list, commit 8bb23cdbb498 raises the minimum makeinfo version required, yet top-level configure.ac continues to be happy with 4.7, thus causing the build to fail with (in my case) 4.12. While possible to work around by passing MAKEINFO=true on all make command lines, it would of course be nice if a fresh release built out of the box. (Note that Component: is wrong, for there not being "bfd" in the list. Afaict only bfd is affected at this point.)
Hi Jan, (In reply to Jan Beulich from comment #0) > As was pointed out on the list, commit 8bb23cdbb498 raises the minimum > makeinfo version required, What is the minimum version now required ? Cheers Nick
(In reply to Nick Clifton from comment #1) > What is the minimum version now required ? I don't know. My vague recollection from the earlier mail thread is that the author of that patch also didn't really know the exact minimum.
Hi Jan, Right, after downloading, building, installing and running lots of different versions of texinfo, I can confirm that support for the node style used by commit 8bb23cdbb498 was added with release 6.8. So the next question is - are you asking that commit 8bb23cdbb498 be reverted, so that the docs will build with older versions of texinfo, or that the top level configure.ac be updated to check for at least texinfo 6.8 ? Cheers Nick
(In reply to Nick Clifton from comment #3) > So the next question is - are you asking that commit 8bb23cdbb498 be > reverted, so that the docs will build with older versions of texinfo, > or that the top level configure.ac be updated to check for at least > texinfo 6.8 ? Well, reverting is what I'm doing locally right now, but I don't view this as a good option. Whether to encode the higher version requirement in the top level configury I'm also not sure of - that largely depends if other sub-components' doc would also soon require newer versions. Plus of course wouldn't that require sync-ing with at least gcc? Would it be possible to limit this to bfd's doc for now? But of course all I really care about is that things build cleanly when configure claims to be happy. I'm not sure what the policy is - it would of course be nice for configure to not fail with too old makeinfo, but for it to instead simply disable doc building (with an appropriate warning).
Right - I have proposed a patch and asked for comments: https://sourceware.org/pipermail/binutils/2023-August/129261.html
(In reply to Jan Beulich from comment #0) > As was pointed out on the list, commit 8bb23cdbb498 raises the minimum > makeinfo version required, yet top-level configure.ac continues to be happy > with 4.7, thus causing the build to fail with (in my case) 4.12 Can you please post the error messages?
Oh never mind, they were here: https://sourceware.org/pipermail/binutils/2023-March/126468.html Given the state of BFD doc stuff, I think it's best to just back out my patch.
Maybe someone with this issue could try: https://sourceware.org/pipermail/binutils/2023-August/129302.html You really only need the first patch.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3b23b03a863d351d2e25daa30b07e23f31350e82 commit 3b23b03a863d351d2e25daa30b07e23f31350e82 Author: Tom Tromey <tom@tromey.com> Date: Wed Aug 30 09:22:53 2023 -0600 Revert "Simplify @node use in BFD documentation" This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8. My earlier patch to simplifify the @node uses in the BFD manual didn't take into account (1) that BFD doesn't use the ordinary texinfo sectioning commands, and (2) that some users are stuck on very ancient versions of makeinfo. This patch reverts the change. I went through the entire manual using the spacebar, trying to find the original problem I reported in the change, but couldn't. I don't know why. Anyway, all this means is that, with this reversion, editing the node structure will be slightly less convenient. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30703 2023-08-30 Tom Tromey <tom@tromey.com> PR binutils/30703 * doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding parameters back to @node.
I backed out the offending patch.
(In reply to Tom Tromey from comment #10) > I backed out the offending patch. Is it possible to backport the revert to binutils-2_41-branch? We are using binutils-2_41-branch, and it is not building for the reasons mentioned above.
(In reply to vvinayag from comment #11) > (In reply to Tom Tromey from comment #10) > > I backed out the offending patch. > > Is it possible to backport the revert to binutils-2_41-branch? We are using > binutils-2_41-branch, and it is not building for the reasons mentioned above. I don't know binutils policy about this, but if it is OK, I can do the work if needed.
(In reply to Tom Tromey from comment #12) > (In reply to vvinayag from comment #11) > > (In reply to Tom Tromey from comment #10) > > > I backed out the offending patch. > > > > Is it possible to backport the revert to binutils-2_41-branch? We are using > > binutils-2_41-branch, and it is not building for the reasons mentioned above. > > I don't know binutils policy about this, but if it is OK, I can > do the work if needed. Who would be the best person to progress this? What could be the reason for not backporting it to binutils 2.41, which is where the issue was first introduced?
(In reply to Tom Tromey from comment #12) > (In reply to vvinayag from comment #11) > > (In reply to Tom Tromey from comment #10) > > > I backed out the offending patch. > > > > Is it possible to backport the revert to binutils-2_41-branch? We are using > > binutils-2_41-branch, and it is not building for the reasons mentioned above. > > I don't know binutils policy about this, but if it is OK, I can > do the work if needed. [Sorry - not paying attention here]. The policy is that it is OK to backport patches to the branch once a release has been made. Hence it is totally OK for you to go ahead and backport your patch.
I should note however that we do not normally make further releases from a branch unless there is an important bug that needs to be fixed. Given that it is possible to work around this build problem, I would not say that it qualifies as being important enough to warrant a 2.41.1 release.
I just got burned by this, after attempting to build 2.41 from https://ftp.gnu.org/gnu/binutils/binutils-2.41.tar.gz I think if there had been a 2.41.1 release, I would have picked that and not had the issue. If a 2.41.1 release is undesirable, another option could be to add a comment to the release notes of 2.41 to specify that makeinfo version 6.8 or higher is required, or set MAKEINFO=true. Is it acceptable to update release notes, post release?
(In reply to Pete Moore from comment #16) > If a 2.41.1 release is undesirable, another option could be to add a comment > to the release notes of 2.41 to specify that makeinfo version 6.8 or higher > is required, or set MAKEINFO=true. > > Is it acceptable to update release notes, post release? By release notes, I assume that you mean the binutils/README file ? Then sure - adding a comment there on the 2.41 branch is certainly reasonable. But this will only be of help to people who download the sources from the branch. Another possibility is to add a description of the problem - and its workaround - to the binutils web page: https://sourceware.org/binutils/ As it happens there is already a precedent for this, as there was another problem with the 2.41 release which needed to be documented on the web page. It may also be of interest to know that the 2.42 release is due out at the end of this month (Jan '24 for those reading these comments after the fact), and all being well, that release will not have this problem.