[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gub fail/local-build-script/new bug?
From: |
David Kastrup |
Subject: |
Re: gub fail/local-build-script/new bug? |
Date: |
Fri, 24 Jan 2020 22:19:52 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
Re: gub fail/local-build-script/new bug?, Dan Eble, 2020/01/24