Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley <thomasmorle...@gmail.com>: > > Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble <d...@faithful.be>: > > > > On Jan 24, 2020, at 15:13, David Kastrup <d...@gnu.org> wrote: > > > > > > Thomas Morley <thomasmorle...@gmail.com> 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 <nine.fierce.ball...@gmail.com> > > 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