[ANNOUNCEMENT] GDB 11 release branch created!

[ANNOUNCEMENT] GDB 11 release branch created!

[Joel Brobecker]

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/

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Andreas Schwab]

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."

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Tom de Vries]

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
...

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Eli Zaretskii]

> 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.

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Tom de Vries]

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

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Eli Zaretskii]

> 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.

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Tom de Vries]

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

Re: [ANNOUNCEMENT] GDB 11 release branch created!

[Eli Zaretskii]

> 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.