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

[David Kastrup]

Dan Eble <address@hidden> writes:

> On Jan 24, 2020, at 15:13, David Kastrup <address@hidden> wrote:
>> 
>> Thomas Morley <address@hidden <mailto: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.

It may be enough to call GCC with --std=g++11 (?) option without
updating GCC itself, but I don't really have an idea.

-- 
David Kastrup