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

[David Kastrup]

Thomas Morley <address@hidden> writes:

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

Dan just a few days ago committed a change requiring C++11 to work.  I
thought we called g++ using -std=c++11 options, but maybe that does
still not work with older compiler/library versions?

-- 
David Kastrup