* [ANNOUNCEMENT] GDB 11 release branch created! @ 2021-07-03 17:52 Joel Brobecker 2021-07-04 9:06 ` Andreas Schwab 0 siblings, 1 reply; 8+ messages in thread From: Joel Brobecker @ 2021-07-03 17:52 UTC (permalink / raw) To: gdb Hello, A quick message to announce that the GDB 11 branch has just been created. The prerelease snapshots will be available at: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.xz The sources are also accessible via GIT: git clone --single-branch --branch=gdb-11-branch git://sourceware.org/git/binutils-gdb.git This announcement has also been posted on the GDB web site at: http://www.sourceware.org/gdb/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-03 17:52 [ANNOUNCEMENT] GDB 11 release branch created! Joel Brobecker @ 2021-07-04 9:06 ` Andreas Schwab 2021-07-05 10:36 ` Tom de Vries 0 siblings, 1 reply; 8+ messages in thread From: Andreas Schwab @ 2021-07-04 9:06 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb On Jul 03 2021, Joel Brobecker wrote: > The prerelease snapshots will be available at: > > ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.xz The tarball contains the file gdb/doc/GDBvn.texi which is a generated file depending on the configuration. This breaks building with --with-system-readline. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-04 9:06 ` Andreas Schwab @ 2021-07-05 10:36 ` Tom de Vries 2021-07-05 12:33 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2021-07-05 10:36 UTC (permalink / raw) To: Andreas Schwab, Joel Brobecker, Eli Zaretskii, Tom Tromey, Bernd Edlinger Cc: gdb On 7/4/21 11:06 AM, Andreas Schwab wrote: > On Jul 03 2021, Joel Brobecker wrote: > >> The prerelease snapshots will be available at: >> >> ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.xz > > The tarball contains the file gdb/doc/GDBvn.texi which is a generated > file depending on the configuration. This breaks building with > --with-system-readline. Hi, I managed to reproduce this. The steps are: - download (or create using src-release.sh) a snapshot - unpack it, into say src - cd src; find -name "*.info*" | xargs rm -f - mkdir build; cd build ; ../src/configure --with-system-readline - cd build; make all-gdb For make output, see below. This can be fixed/worked around by doing: ... $ rm -f gdb/doc/GDBvn.texi ... as Andreas did here ( https://build.opensuse.org/package/rdiff/home:AndreasSchwab/gdb?linkrev=base&rev=143 ). My guess is that this is a regression since: ... commit ab954e4a53cab8c33728e6708695abc1616c90b1 Author: Bernd Edlinger <bernd.edlinger@hotmail.de> Date: Wed Nov 25 18:52:49 2020 +0100 Fix building gdb release from tar file without makeinfo Add GDBvn.texi and version.subst to the release tar file, so the gdb.info does not need makeinfo. This avoids the need for makeinfo to be available. ... Interestingly, there are previous commits related to GDBvn.texi where the submission emails show the same problem ( https://sourceware.org/pipermail/gdb-patches/2011-January/078980.html ), and the final conclusion of that discussion ( https://sourceware.org/pipermail/gdb-patches/2011-January/079001.html ) is: ... So, unless anyone else objects, removing GDBvn.texi from the distributed files is the solution. ... Thanks, - Tom ... make[2]: Entering directory '/home/vries/upstream/tmp/build/gdb' make[3]: Entering directory '/home/vries/upstream/tmp/build/gdb/doc' (test "ln -s" = "ln -s" && \ ln -s ../../../src/gdb/doc/all-cfg.texi gdb-cfg.texi) || \ ln ../../../src/gdb/doc/all-cfg.texi gdb-cfg.texi || \ cp ../../../src/gdb/doc/all-cfg.texi gdb-cfg.texi makeinfo --split-size=5000000 -DHAVE_MAKEINFO_CLICK -I ../../../src/gdb/doc/../mi -I ../../../src/gdb/doc \ -o gdb.info ../../../src/gdb/doc/gdb.texinfo ../../../src/gdb/doc/gdb.texinfo:38160: @include: could not find rluser.texi ../../../src/gdb/doc/gdb.texinfo:38161: @include: could not find hsuser.texi ../../../src/gdb/doc/gdb.texinfo:25774: @xref reference to nonexistent node `Command Line Editing' ../../../src/gdb/doc/gdb.texinfo:25806: @xref reference to nonexistent node `Using History Interactively' ../../../src/gdb/doc/gdb.texinfo:25902: @xref reference to nonexistent node `Event Designators' ../../../src/gdb/doc/gdb.texinfo:28508: @pxref reference to nonexistent node `Command Line Editing' ../../../src/gdb/doc/gdb.texinfo:172: @menu reference to nonexistent node `Command Line Editing' ../../../src/gdb/doc/gdb.texinfo:173: @menu reference to nonexistent node `Using History Interactively' make[3]: *** [Makefile:491: gdb.info] Error 1 make[3]: Leaving directory '/home/vries/upstream/tmp/build/gdb/doc' make[2]: *** [Makefile:1973: subdir_do] Error 1 make[2]: Leaving directory '/home/vries/upstream/tmp/build/gdb' make[1]: *** [Makefile:1639: all] Error 2 make[1]: Leaving directory '/home/vries/upstream/tmp/build/gdb' make: *** [Makefile:10116: all-gdb] Error 2 ... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-05 10:36 ` Tom de Vries @ 2021-07-05 12:33 ` Eli Zaretskii 2021-07-05 13:36 ` Tom de Vries 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2021-07-05 12:33 UTC (permalink / raw) To: Tom de Vries; +Cc: schwab, brobecker, tom, bernd.edlinger, gdb > Cc: gdb@sourceware.org > From: Tom de Vries <tdevries@suse.de> > Date: Mon, 5 Jul 2021 12:36:00 +0200 > > > The tarball contains the file gdb/doc/GDBvn.texi which is a generated > > file depending on the configuration. This breaks building with > > --with-system-readline. > > I managed to reproduce this. > > The steps are: > - download (or create using src-release.sh) a snapshot > - unpack it, into say src > - cd src; find -name "*.info*" | xargs rm -f > - mkdir build; cd build ; ../src/configure --with-system-readline > - cd build; make all-gdb > > For make output, see below. > > This can be fixed/worked around by doing: > ... > $ rm -f gdb/doc/GDBvn.texi > ... > as Andreas did here ( > https://build.opensuse.org/package/rdiff/home:AndreasSchwab/gdb?linkrev=base&rev=143 > ). > > My guess is that this is a regression since: > ... > commit ab954e4a53cab8c33728e6708695abc1616c90b1 > Author: Bernd Edlinger <bernd.edlinger@hotmail.de> > Date: Wed Nov 25 18:52:49 2020 +0100 > > Fix building gdb release from tar file without makeinfo > > Add GDBvn.texi and version.subst to the release tar file, > so the gdb.info does not need makeinfo. > > This avoids the need for makeinfo to be available. > ... > > Interestingly, there are previous commits related to GDBvn.texi where > the submission emails show the same problem ( > https://sourceware.org/pipermail/gdb-patches/2011-January/078980.html ), > and the final conclusion of that discussion ( > https://sourceware.org/pipermail/gdb-patches/2011-January/079001.html ) is: > ... > So, unless anyone else objects, removing GDBvn.texi from the > distributed files is the solution. But that would again bring the problem that inclusion was intended to fix, no? Wouldn't it be better to modify the configure script so that READLINE_TEXI_INCFLAG always includes "-I ${READLINE_DIR}"? Or did I misunderstand the reason why makeinfo doesn't find the Readline manual? Thanks. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-05 12:33 ` Eli Zaretskii @ 2021-07-05 13:36 ` Tom de Vries 2021-07-05 15:34 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2021-07-05 13:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: brobecker, tom, bernd.edlinger, gdb On 7/5/21 2:33 PM, Eli Zaretskii wrote: >> Cc: gdb@sourceware.org >> From: Tom de Vries <tdevries@suse.de> >> Date: Mon, 5 Jul 2021 12:36:00 +0200 >> >>> The tarball contains the file gdb/doc/GDBvn.texi which is a generated >>> file depending on the configuration. This breaks building with >>> --with-system-readline. >> >> I managed to reproduce this. >> >> The steps are: >> - download (or create using src-release.sh) a snapshot >> - unpack it, into say src >> - cd src; find -name "*.info*" | xargs rm -f >> - mkdir build; cd build ; ../src/configure --with-system-readline >> - cd build; make all-gdb >> >> For make output, see below. >> >> This can be fixed/worked around by doing: >> ... >> $ rm -f gdb/doc/GDBvn.texi >> ... >> as Andreas did here ( >> https://build.opensuse.org/package/rdiff/home:AndreasSchwab/gdb?linkrev=base&rev=143 >> ). >> >> My guess is that this is a regression since: >> ... >> commit ab954e4a53cab8c33728e6708695abc1616c90b1 >> Author: Bernd Edlinger <bernd.edlinger@hotmail.de> >> Date: Wed Nov 25 18:52:49 2020 +0100 >> >> Fix building gdb release from tar file without makeinfo >> >> Add GDBvn.texi and version.subst to the release tar file, >> so the gdb.info does not need makeinfo. >> >> This avoids the need for makeinfo to be available. >> ... >> >> Interestingly, there are previous commits related to GDBvn.texi where >> the submission emails show the same problem ( >> https://sourceware.org/pipermail/gdb-patches/2011-January/078980.html ), >> and the final conclusion of that discussion ( >> https://sourceware.org/pipermail/gdb-patches/2011-January/079001.html ) is: >> ... >> So, unless anyone else objects, removing GDBvn.texi from the >> distributed files is the solution. > > But that would again bring the problem that inclusion was intended to > fix, no? > > Wouldn't it be better to modify the configure script so that > READLINE_TEXI_INCFLAG always includes "-I ${READLINE_DIR}"? Or did I > misunderstand the reason why makeinfo doesn't find the Readline > manual? I was not trying to suggest a fix, but merely trying to point out that we seem to be going forth and back on this (that, and the reproducer seemed to be worth sharing at that point). Anyway, by now I've investigated a bit further. The difficulty seems to be that the documentation is dependent on configure options. I can think of two clean ways to handle pre-generated docs in such a case: - not including pre-generated docs in the source tarball - generating a version of the docs for the source tarball, that conservatively agrees with all configure choices. Before the regressing commit, we had the first situation. After the commit, we no longer have the first, but also not the second (and, we have the build problem). To give an example of what I'm concerned about: say a user has a system without makeinfo, and builds with --with-system-readline. Then the gdb documentation point to the in-source readline docs, which does not necessarily agree with the actually used readline version. So, I think that before thinking about solving build problems, we first have to get clear what kind of pre-generated docs we want, if any. Thanks, - Tom ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-05 13:36 ` Tom de Vries @ 2021-07-05 15:34 ` Eli Zaretskii 2021-07-06 14:58 ` Tom de Vries 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2021-07-05 15:34 UTC (permalink / raw) To: Tom de Vries; +Cc: brobecker, tom, bernd.edlinger, gdb > Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de, > gdb@sourceware.org > From: Tom de Vries <tdevries@suse.de> > Date: Mon, 5 Jul 2021 15:36:07 +0200 > > > Wouldn't it be better to modify the configure script so that > > READLINE_TEXI_INCFLAG always includes "-I ${READLINE_DIR}"? Or did I > > misunderstand the reason why makeinfo doesn't find the Readline > > manual? > > I was not trying to suggest a fix, but merely trying to point out that > we seem to be going forth and back on this (that, and the reproducer > seemed to be worth sharing at that point). > > Anyway, by now I've investigated a bit further. > > The difficulty seems to be that the documentation is dependent on > configure options. Yes, and that should probably change (I have an idea for how to do that). But the change isn't so trivial, so I think it isn't appropriate for the branch. Therefore, I tried to propose a band-aid: have the readline/readline/doc directory be _always_ on the makeinfo's include path, so that if someone reconfigures GDB like in the reproducer, they still get a successful build, albeit with a couple of sections in the manual they don't need. Could you please see if my proposal solves the immediate problem? And if not, explain what I missed? > I can think of two clean ways to handle pre-generated docs in such a case: > - not including pre-generated docs in the source tarball That'd contradict GNU conventions: we always include the generated Info manuals in the release tarballs. > - generating a version of the docs for the source > tarball, that conservatively agrees with all configure choices. I think this is sufficiently complex to avoid doing that on the branch. We could try this on master, of course. But right now, I'd like to fix the branch so that we don't have a regression, while still allowing people to build GDB without having Texinfo installed. > To give an example of what I'm concerned about: say a user has a system > without makeinfo, and builds with --with-system-readline. Then the gdb > documentation point to the in-source readline docs, which does not > necessarily agree with the actually used readline version. That's true, but I don't see that as a serious enough problem to delay the release of GDB 11. Of course, it isn't my call, eventually. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-05 15:34 ` Eli Zaretskii @ 2021-07-06 14:58 ` Tom de Vries 2021-07-06 15:50 ` Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Tom de Vries @ 2021-07-06 14:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: brobecker, tom, bernd.edlinger, gdb On 7/5/21 5:34 PM, Eli Zaretskii wrote: >> Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de, >> gdb@sourceware.org >> From: Tom de Vries <tdevries@suse.de> >> Date: Mon, 5 Jul 2021 15:36:07 +0200 >> >>> Wouldn't it be better to modify the configure script so that >>> READLINE_TEXI_INCFLAG always includes "-I ${READLINE_DIR}"? Or did I >>> misunderstand the reason why makeinfo doesn't find the Readline >>> manual? >> >> I was not trying to suggest a fix, but merely trying to point out that >> we seem to be going forth and back on this (that, and the reproducer >> seemed to be worth sharing at that point). >> >> Anyway, by now I've investigated a bit further. >> >> The difficulty seems to be that the documentation is dependent on >> configure options. > > Yes, and that should probably change (I have an idea for how to do > that). Cool. > But the change isn't so trivial, so I think it isn't > appropriate for the branch. Ack. > Therefore, I tried to propose a band-aid: > have the readline/readline/doc directory be _always_ on the makeinfo's > include path, so that if someone reconfigures GDB like in the > reproducer, they still get a successful build, albeit with a couple of > sections in the manual they don't need. > AFAIU, the problem is not that users get a couple of sections in the manual they don't need. The problem is that the users get the incorrect version of a section of the manual. > Could you please see if my proposal solves the immediate problem? And > if not, explain what I missed? > Sure, no problem. I did this: ... - READLINE_TEXI_INCFLAG= + READLINE_TEXI_INCFLAG='-I $(READLINE_DIR)' ... in src/gdb/configure and managed to finish the build. >> I can think of two clean ways to handle pre-generated docs in such a case: >> - not including pre-generated docs in the source tarball > > That'd contradict GNU conventions: we always include the generated > Info manuals in the release tarballs. > >> - generating a version of the docs for the source >> tarball, that conservatively agrees with all configure choices. > > I think this is sufficiently complex to avoid doing that on the > branch. We could try this on master, of course. But right now, I'd > like to fix the branch so that we don't have a regression, while still > allowing people to build GDB without having Texinfo installed. > >> To give an example of what I'm concerned about: say a user has a system >> without makeinfo, and builds with --with-system-readline. Then the gdb >> documentation point to the in-source readline docs, which does not >> necessarily agree with the actually used readline version. > > That's true, but I don't see that as a serious enough problem to delay > the release of GDB 11. Of course, it isn't my call, eventually. > Well, I don't see any reason to delay the release. I'd say the easiest way to fix the problem is to revert the commit that introduced the problem. Thanks, - Tom ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] GDB 11 release branch created! 2021-07-06 14:58 ` Tom de Vries @ 2021-07-06 15:50 ` Eli Zaretskii 0 siblings, 0 replies; 8+ messages in thread From: Eli Zaretskii @ 2021-07-06 15:50 UTC (permalink / raw) To: Tom de Vries; +Cc: brobecker, tom, bernd.edlinger, gdb > Cc: brobecker@adacore.com, tom@tromey.com, bernd.edlinger@hotmail.de, > gdb@sourceware.org > From: Tom de Vries <tdevries@suse.de> > Date: Tue, 6 Jul 2021 16:58:28 +0200 > > > Therefore, I tried to propose a band-aid: > > have the readline/readline/doc directory be _always_ on the makeinfo's > > include path, so that if someone reconfigures GDB like in the > > reproducer, they still get a successful build, albeit with a couple of > > sections in the manual they don't need. > > AFAIU, the problem is not that users get a couple of sections in the > manual they don't need. The problem is that the users get the incorrect > version of a section of the manual. I think this is a minor problem. How different could be the Readline we have in the tarball vs the one installed on the user's system? Readline is a relatively stable package, so changes are likely minor. > I did this: > ... > - READLINE_TEXI_INCFLAG= > + READLINE_TEXI_INCFLAG='-I $(READLINE_DIR)' > ... > in src/gdb/configure and managed to finish the build. So my recommendation is to go with this solution on the release branch. I will try to think about a cleaner fix on master. > I'd say the easiest way to fix the problem is to revert the commit that > introduced the problem. I wouldn't recommend that. In fact, I do have Texinfo installed, but I nevertheless am always slightly annoyed by the fact that building GDB always rebuilds the Info manual for some reason. I hope that commit solved this. Joel, it's your call. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-07-06 15:50 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-03 17:52 [ANNOUNCEMENT] GDB 11 release branch created! Joel Brobecker 2021-07-04 9:06 ` Andreas Schwab 2021-07-05 10:36 ` Tom de Vries 2021-07-05 12:33 ` Eli Zaretskii 2021-07-05 13:36 ` Tom de Vries 2021-07-05 15:34 ` Eli Zaretskii 2021-07-06 14:58 ` Tom de Vries 2021-07-06 15:50 ` Eli Zaretskii
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).