lilypond-devel
[Top][All Lists]
Advanced

[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 21:13:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> Hi,
>
> although we are discussing other methods to do releases, I'd expect
> for 2.20 we still will use gub.

No alternative here, really.

> Furthermore I promised Arnold from the german forum to do some custom
> windows-installer with some code which may fix fix issue 4943 and
> probably other related windows-only bugs.
>
> Thus I fired up my local gub, made it up to date and tried the nice
> gubllb-script by Knut Petersen.
> https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00066.html
> First I tried from my local lilypond-git-master.
> Regrettable it fails.
> But worked half a year back.
> I'll attach the script. Someone with some insights?
>
>
>
> Then I tried directly ´make lilypond´ (which uses our official
> repo),though, it fails as well. Log goes wrong starting with:
>
> Making flower/out/offset.o < cc
> In file included from
> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/interval.cc:22:0:
> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:
> 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
>    using std::to_string;
>               ^
>
> Looks like a problem from a recent change.
>
> 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 ()
>
>
> Any hints?

Our current source code assumes more or less C++11 I think, and GUB
compilers might not be up to it?

Another possibility is that std::to_string is defined by accident (by
some include file including another file) and this does not work for all
implementations of the library.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]