Re: gub fail/local-build-script/new bug?

[Thomas Morley]

Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley
<address@hidden>:
>
> Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble <address@hidden>:
> >
> > On Jan 24, 2020, at 15:13, David Kastrup <address@hidden> wrote:
> >
> >
> > Thomas Morley <address@hidden> writes:
> >
> > ...
> >
> > In member function 'std::string Interval_t<T>::to_string() const':
> > /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
> > error: 'std::to_string' has not been declared
> >
> > ...
> >
> > Probably:
> >
> > commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
> > Author: Dan Eble <address@hidden>
> > Date:   Sat Jan 11 08:55:36 2020 -0500
> >
> >    Issue 5659/8: Remove Interval_t<T>::T_to_string ()
> >
> >
> > This is probably not the root cause, for though this tries to use 
> > std::to_string(), the reason it does so is because several preceding 
> > commits that removed ::to_string() overloads that were duplicating the 
> > function of std::to_string().  I think if you reverted just this commit, 
> > you'd hit an undefined std::to_string() elsewhere.
> >
> > Our current source code assumes more or less C++11 I think, and GUB
> > compilers might not be up to it?
> >
> >
> > This seems likely.  (Have I mentioned how tiresome GUB is?  I know it's 
> > been a while since anyone complained about it.)
> >
> > Can we upgrade GUB, or should I start working to restore the global 
> > ::to_string() functions?  Newer systems are better off with things the way 
> > they are, but I don't see a third option.
> > —
> > Dan
> >
>
> Well, I can't do any reasonable GUB-fixing, it's out of my depth.
>
> Also, your relevant patches are out of my depth as well. Though,
> nobody objected during review, thus I think we should keep them.
>
> But I happily test things :)
> Right now I try a GUB-build from a local branch containing nothing
> else than already released 2.19.83. (with said gublbb and most recent
> GUB)
> If it fails (it worked half a year ago), than I suspect a GUB-problem.
> And I may try to bisect GUB, although this will be very tedious...
> If success I may try going lilypond-upstream.
>
> Cheers,
>   Harm

This GUB-build succeded.
Since I used the most up to date GUB, I suspect the encountered
problem somewhere in LilyPond not in GUB.
I'll first make a patched windows-installer (see above) and then I'll
try to go upstream.

Cheers,
  Harm