GUB fail
David K warned me this morning that my attempt to build 2.19.84 might fail
with a compiler error. It did. The error output is:
/home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
}
^
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/libexec/gcc/i686-apple-darwin8/4.9.4/cc1plus:
tried to open () file
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
/home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1:
internal compiler error: Aborted
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/libexec/gcc/i686-apple-darwin8/4.9.4/cc1plus:
tried to open () file
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
{standard input}:unknown:Undefined local symbol
L__ZNSs4_Rep10_M_destroyERKSaIcE$stub
i686-apple-darwin8-g++: internal compiler error: Aborted (program cc1plus)
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/bin/i686-apple-darwin8-g++:
tried to open () file
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
Aborted (core dumped)
make[1]: *** [out/rational.o] Error 134
make[1]: Leaving directory
`/home/gub/NewGub/gub/target/darwin-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower'
make: *** [all] Error 2
Command barfed: cd
/home/gub/NewGub/gub/target/darwin-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20
&& make -j16 TARGET_PYTHON="/usr/bin/env python"
--
Phil Holmes
Re: gub fail/local-build-script/new bug?
Hi all, Am 25.01.2020 um 10:02 schrieb Thomas Morley: [snip] 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. I tried to reproduce the problem, first for the linux-64 target. So I wiped the gub directory completely and used current gub 77cd66468e535f1c6c213624be2fd6ca75b685ac and did bin/gub linux-64::lilypond Everything went fine it seems, at least it got through the lilypond compilation process. (I did not get your error you got, but IIRC it was the freebsd-x86 target that failed for you, right?) But then I got during lilypond install stage: invoking cd /home/dev/gub/target/linux-64/install/lilypond--root/usr/share/lilypond && mv 2.21.0 current invoking cd /home/dev/gub/target/linux-64/install/lilypond--root/usr/lib/lilypond && mv 2.21.0 current /bin/sh: 1: cd: can't cd to /home/dev/gub/target/linux-64/install/lilypond--root/usr/lib/lilypond Command barfed: cd /home/dev/gub/target/linux-64/install/lilypond--root/usr/lib/lilypond && mv 2.21.0 current I checked this and can confirm that the directory .../usr/lib/lilypond is missing. Could not manage to look through 2000+ lines of build log to get a clue where the underlying problem is, however. Cheers, Michael
Re: gub fail/local-build-script/new bug?
Thomas Morley writes: > Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley > : >> >> Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble : >> > >> > On Jan 24, 2020, at 15:13, David Kastrup wrote: >> > >> > >> > Thomas Morley writes: >> > >> > ... >> > >> > In member function 'std::string Interval_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 >> > Date: Sat Jan 11 08:55:36 2020 -0500 >> > >> >Issue 5659/8: Remove Interval_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
Re: gub fail/local-build-script/new bug?
Am Fr., 24. Jan. 2020 um 22:28 Uhr schrieb Thomas Morley : > > Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble : > > > > On Jan 24, 2020, at 15:13, David Kastrup wrote: > > > > > > Thomas Morley writes: > > > > ... > > > > In member function 'std::string Interval_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 > > Date: Sat Jan 11 08:55:36 2020 -0500 > > > >Issue 5659/8: Remove Interval_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
Re: gub fail/local-build-script/new bug?
On Jan 24, 2020, at 16:19, David Kastrup wrote:
>
> It may be enough to call GCC with --std=g++11 (?) option without
> updating GCC itself, but I don't really have an idea.
GUB is using GCC 4.9.4 [1].
I've compiled the following program with Compiler Explorer [2] using that
version of g++:
#include
int main()
{
std::to_string(13);
return 0;
}
With the default command line, the compiler complains that "'to_string' is not
a member of 'std'". After adding the option "-std=c++11", the program compiles.
In stepmake/stepmake/c++-vars.make, EXTRA_CXXFLAGS is defined with "-std=c++11"
in it, so I don't understand why Harm is having trouble.
Could something in GUB be overriding that option?
—
Dan
[1] https://lists.gnu.org/archive/html/lilypond-devel/2019-12/msg00072.html
[2] https://godbolt.org
Re: gub fail/local-build-script/new bug?
Am Fr., 24. Jan. 2020 um 23:28 Uhr schrieb Michael Käppler : > > Am 24.01.2020 um 22:28 schrieb Thomas Morley: > > > > 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. > > I tried Knut's script too, while testing Dan's patches for issue 5658. > I did not work for me, either. > Your description from mid-2019 > https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00065.html > worked like a charm, however. > > Did not have time to look at Knut's script. > > Cheers, > Michael > > I totaly forgot I wrote up a way using a daemon manually without using Knut's script. I may resort to it lol Thanks, Harm
Re: gub fail/local-build-script/new bug?
Am 24.01.2020 um 22:28 schrieb Thomas Morley: 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. I tried Knut's script too, while testing Dan's patches for issue 5658. I did not work for me, either. Your description from mid-2019 https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00065.html worked like a charm, however. Did not have time to look at Knut's script. Cheers, Michael
Re: gub fail/local-build-script/new bug?
Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble : > > On Jan 24, 2020, at 15:13, David Kastrup wrote: > > > Thomas Morley writes: > > ... > > In member function 'std::string Interval_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 > Date: Sat Jan 11 08:55:36 2020 -0500 > >Issue 5659/8: Remove Interval_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
Re: gub fail/local-build-script/new bug?
Dan Eble writes: > On Jan 24, 2020, at 15:13, David Kastrup wrote: >> >> Thomas Morley mailto:thomasmorle...@gmail.com>> >> writes: > ... >>> In member function 'std::string Interval_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 >>> Date: Sat Jan 11 08:55:36 2020 -0500 >>> >>>Issue 5659/8: Remove Interval_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?
On Jan 24, 2020, at 15:13, David Kastrup wrote: > > Thomas Morley mailto:thomasmorle...@gmail.com>> > writes: ... >> In member function 'std::string Interval_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 >> Date: Sat Jan 11 08:55:36 2020 -0500 >> >>Issue 5659/8: Remove Interval_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
Re: gub fail/local-build-script/new bug?
Thomas Morley 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::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 > Date: Sat Jan 11 08:55:36 2020 -0500 > > Issue 5659/8: Remove Interval_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
gub fail/local-build-script/new bug?
Hi, although we are discussing other methods to do releases, I'd expect for 2.20 we still will use gub. 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::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 Date: Sat Jan 11 08:55:36 2020 -0500 Issue 5659/8: Remove Interval_t::T_to_string () Any hints? Cheers, Harm gubllb Description: Binary data
Re: GUB fail
Thanks. I've merged it and pulled it and am now trying a build again. -- Phil Holmes - Original Message - From: "Masamichi Hosoda" <truer...@trueroad.jp> To: <m...@philholmes.net> Cc: <lilypond-devel@gnu.org>; <truer...@sea.plala.or.jp> Sent: Sunday, February 12, 2017 2:59 PM Subject: Re: GUB fail GUB is not building correctly for me. The end of the command line output is: I've created a patch. https://github.com/gperciva/gub/pull/36 Sorry, I've not tested it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
> GUB is not building correctly for me. The end of the command line > output is: I've created a patch. https://github.com/gperciva/gub/pull/36 Sorry, I've not tested it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail
GUB is not building correctly for me. The end of the command line output is: building package: mingw::lilypond *** Stage: download (lilypond, mingw) *** Stage: untar (lilypond, mingw) *** Stage: patch (lilypond, mingw) *** Stage: autoupdate (lilypond, mingw) *** Stage: configure (lilypond, mingw) *** Stage: compile (lilypond, mingw) *** Stage: install (lilypond, mingw) Command barfed: cp /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/lib/lilypond/*/python/* /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/bin Tail of target/mingw/log/lilypond.log invoking install -m755 /home/gub/NewGub/gub/target/mingw/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/out/lilypond-console /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/bin/lilypond.exe invoking cp /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/lib/lilypond/*/python/* /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/bin cp: cannot stat '/home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/lib/lilypond/*/python/*': No such file or directory Command barfed: cp /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/lib/lilypond/*/python/* /home/gub/NewGub/gub/target/mingw/install/lilypond-2.19.55-root/usr/bin Tail of target/mingw/log/lilypond.log *** Failed target: mingw::lilypond -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
- Original Message - From: "Masamichi Hosoda" <truer...@trueroad.jp> To: <m...@philholmes.net> Cc: <lilypond-devel@gnu.org> Sent: Sunday, December 04, 2016 11:56 AM Subject: Re: GUB fail I've had my last 2 tries to compile a GUB build today fail with the same error. The last relevant part of the log is: Would you show me the whole log file? If I understand correctly, I've found out the cause. Is there the following line in the log file? GPL Ghostscript 9.20: Can't find initialization file gs_init.ps. I've created a pull request. https://github.com/gperciva/gub/pull/32 That's fixed it. Thanks very much. You are a superstar. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
>> I've had my last 2 tries to compile a GUB build today fail with the >> same error. The last relevant part of the log is: > > Would you show me the whole log file? If I understand correctly, I've found out the cause. Is there the following line in the log file? GPL Ghostscript 9.20: Can't find initialization file gs_init.ps. I've created a pull request. https://github.com/gperciva/gub/pull/32 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
> I've had my last 2 tries to compile a GUB build today fail with the > same error. The last relevant part of the log is: Would you show me the whole log file? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail
I've had my last 2 tries to compile a GUB build today fail with the same error. The last relevant part of the log is: invoking gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -slilypond-datadir=v2.19.51-1/share/lilypond/current -r101 -sOutputFile=/home/gub/NewGub/gub/uploads/webtest/v2.19.52-1/compare-v2.19.51-1/v2.19.51-1/test-output-distance.png -dNOSAFER -dEPSCrop -q -dNOPAUSE v2.19.51-1/test-output-distance.eps -c quit Traceback (most recent call last): File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 1348, in ? main () File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 1345, in main compare_tree_pairs (zip (args[0::2], args[1::2]), out, options.threshold) File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 1060, in compare_tree_pairs data.create_html_result_page (dest_dir, threshold) File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 1042, in create_html_result_page link.link_files_for_html (dest_dir) File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 659, in link_files_for_html to_compare = self.create_images (dest_dir) File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 649, in create_images system (cmd) File "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py", line 1090, in system assert stat == 0 AssertionError -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail in mingw build - Issue 4462
I'm getting a failure to build GUB, as shown below: /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc: In member function 'void Scm_module::import()': /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:71:7: error: expected primary- expression before 'struct' SCM interface = scm_c_resolve_module (name_); ^ /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:76:5: error: expected primary- expression before 'struct' interface = Guile_user::module_public_interface (interface); ^ /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:80:24: error: expected primary- expression before 'struct' p-var_-import (interface, p-name_); ^ /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:85:13: error: expected primary- expression before 'struct' module_ = interface; ^ make[1]: *** [out/lily-modules.o] Error 1 Looks like this comes from Issue 4462: perhaps 'interface' is a reserved word for the Windows compiler? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail in mingw build - Issue 4462
Phil Holmes m...@philholmes.net writes: I'm getting a failure to build GUB, as shown below: /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc: In member function 'void Scm_module::import()': /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:71:7: error: expected primary- expression before 'struct' SCM interface = scm_c_resolve_module (name_); ^ /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:76:5: error: expected primary- expression before 'struct' interface = Guile_user::module_public_interface (interface); ^ /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:80:24: error: expected primary- expression before 'struct' p-var_-import (interface, p-name_); ^ /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/lily-modules.cc:85:13: error: expected primary- expression before 'struct' module_ = interface; ^ make[1]: *** [out/lily-modules.o] Error 1 Looks like this comes from Issue 4462: perhaps 'interface' is a reserved word for the Windows compiler? Or its system libraries. It's only a small part of the code, I'll push a rename presently. Expect it in staging in 5 minutes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
I presume this is owing to the changes to font handling that Masamichi has made, and I also presume that I can fix this by updating GUB. Problem is, I'm confused with how to go about the latter. My current GUB build environment is cloned from https://github.com/trueroad/gub and is built from the branch origin/pango-1.28. I can see there are updates to this repo, but Github is not currently displaying to me the latest commits. So: what's the easiest way to pick up the needed updates to git? lilypond document http://www.lilypond.org/doc/v2.19/Documentation/contributor/other-repositories says that GUB's repository is https://github.com/gperciva/gub It is not my repository https://github.com/trueroad/gub My repository's upstream is gperciva/gub/master. I think that my repository's branch pango-1.28 is obsolete. It has been merged to upstream. And, If I understand correctly, the branch master of https://github.com/gperciva/gub has already changed configure's font option. https://github.com/gperciva/gub/pull/14 So, I think that the most easy way is to re-clone from https://github.com/gperciva/gub Or, perhaps you might be able to change the origin with the following commands. $ git remote rm origin $ git remote add origin g...@github.com:gperciva/gub.git $ git fetch origin $ git checkout master $ git merge origin/master ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail
Probably a request for help from Masamichi, but if anyone else can help, please chime in. My GUB build this morning has failed as follows: config.status: creating config.hh configure: WARNING: unrecognized options: --enable-shared, --disable-static, --disable-silent-rules, --with-ncsb-dir WARNING: Please consider installing optional programs or files: dblatex ERROR: Please install required programs: International Century Schoolbook L fonts (make sure the fc-list utility can see them, or use --with-fonts-dir) International Nimbus Sans L fonts International Nimbus Mono L fonts I presume this is owing to the changes to font handling that Masamichi has made, and I also presume that I can fix this by updating GUB. Problem is, I'm confused with how to go about the latter. My current GUB build environment is cloned from https://github.com/trueroad/gub and is built from the branch origin/pango-1.28. I can see there are updates to this repo, but Github is not currently displaying to me the latest commits. So: what's the easiest way to pick up the needed updates to git? TIA -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
Any advice anyone? Would you show me the whole ghostscript.log and /home/gub/NewGub/gub/target/darwin-ppc/build/soobj/arch.h ? Attached. Thank you. It seems 32 bit hosts cross compiling issue. I've updated the branch. https://github.com/trueroad/gub/commit/27a90b6b8c6d2f2acb1062a190ab13f93657e4b5 Would you try again? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
On 2015年3月29日 22:25:13 JST, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Masamichi HOSODA truer...@trueroad.jp To: m...@philholmes.net Cc: lilypond-devel@gnu.org Any advice anyone? Would you show me the whole ghostscript.log and /home/gub/NewGub/gub/target/darwin-ppc/build/soobj/arch.h ? Attached. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Thank you. It seems 32 bit hosts cross compiling issue. I've updated the branch. https://github.com/trueroad/gub/commit/27a90b6b8c6d2f2acb1062a190ab13f93657e4b5 Would you try again? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail
I have pulled Masamichi Hosoda's new pango-1.28 branch from his github
repository and the GUB build has failed building Ghostscript. I get the
following:
building package: darwin-ppc::ghostscript
*** Stage: download (ghostscript, darwin-ppc)
*** Stage: untar (ghostscript, darwin-ppc)
*** Stage: patch (ghostscript, darwin-ppc)
*** Stage: autoupdate (ghostscript, darwin-ppc)
*** Stage: configure (ghostscript, darwin-ppc)
*** Stage: compile (ghostscript, darwin-ppc)
Command barfed: cd
/home/gub/NewGub/gub/target/darwin-ppc/build/ghostscript-9.15
make TARGET=darwin CFLAGS+=-DHAVE_SYS_TIME_H=1
INCLUDE=/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include
PSDOCDIR=/usr/share/doc PSMANDIR=/usr/share/man XLDFLAGS='' so
ghostscript.log shows:
powerpc-apple-darwin8-gcc -D__ppc__ -DHAVE_MKSTEMP -DHAVE_FSEEKO
-DHAVE_SETLOCALE -DHAVE_BSWAP32 -DHAVE_STRERROR -fPIC -O2 -fPIC
-DSTDC_HEADERS -Wall -Wundef -Wwrite-strings -Wno-strict-aliasing
-Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1
-DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1
-DHAVE_INTTYPES_H=1 -DGX_COLOR_INDEX_TYPE=unsigned long long
-DUSE_LIBICONV_GNU -I/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include
-DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\/usr/lib/ghostscript/9.15\
-I/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/psi -I./soobj
-I./soobj -I/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/base
-I/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/devices
-o ./soobj/zchar1.o
-c /home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/psi/zchar1.c
In file included from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/base/gsdcolor.h:26:0,
from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/base/gxdevcli.h:25,
from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/base/gxdevice.h:23,
from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/psi/zchar1.c:24:
/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/base
/gxcindex.h:58:78: warning: division by zero [-Wdiv-by-zero]
enum { ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE =
1/!!(ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX_TYPE)) };
^
/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/
base/gxcindex.h:58:8: error: enumerator value for
'ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE'
is not an integer constant
enum { ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE
= 1/!!(ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX_TYPE)) };
^
make[2]: *** [soobj/zchar1.o] Error 1
Any advice anyone?
Would you show me the whole ghostscript.log and
/home/gub/NewGub/gub/target/darwin-ppc/build/soobj/arch.h ?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail
I have pulled Masamichi Hosoda's new pango-1.28 branch from his github
repository and the GUB build has failed building Ghostscript. I get the
following:
building package: darwin-ppc::ghostscript
*** Stage: download (ghostscript, darwin-ppc)
*** Stage: untar (ghostscript, darwin-ppc)
*** Stage: patch (ghostscript, darwin-ppc)
*** Stage: autoupdate (ghostscript, darwin-ppc)
*** Stage: configure (ghostscript, darwin-ppc)
*** Stage: compile (ghostscript, darwin-ppc)
Command barfed: cd /home/gub/NewGub/gub/target/darwin-ppc/build/ghostscript-9.15
make TARGET=darwin CFLAGS+=-DHAVE_SYS_TIME_H=1
INCLUDE=/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include
PSDOCDIR=/usr/share/doc PSMANDIR=/usr/share/man XLDFLAGS='' so
ghostscript.log shows:
powerpc-apple-darwin8-gcc -D__ppc__ -DHAVE_MKSTEMP -DHAVE_FSEEKO
-DHAVE_SETLOCALE -DHAVE_BSWAP32 -DHAVE_STRERROR -fPIC -O2 -fPIC
-DSTDC_HEADERS -Wall -Wundef -Wwrite-strings -Wno-strict-aliasing
-Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1
-DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1
-DHAVE_INTTYPES_H=1 -DGX_COLOR_INDEX_TYPE=unsigned long long
-DUSE_LIBICONV_GNU -I/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include
-DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\/usr/lib/ghostscript/9.15\
-I/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/psi -I./soobj
-I./soobj -I/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/base
-I/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/devices
-o ./soobj/zchar1.o
-c /home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/psi/zchar1.c
In file included from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/base/gsdcolor.h:26:0,
from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/base/gxdevcli.h:25,
from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/base/gxdevice.h:23,
from /home/gub/NewGub/gub/target/darwin-ppc/src
/ghostscript-9.15/psi/zchar1.c:24:
/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/base
/gxcindex.h:58:78: warning: division by zero [-Wdiv-by-zero]
enum { ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE =
1/!!(ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX_TYPE)) };
^
/home/gub/NewGub/gub/target/darwin-ppc/src/ghostscript-9.15/
base/gxcindex.h:58:8: error: enumerator value for
'ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE'
is not an integer constant
enum { ARCH_SIZEOF_GX_COLOR_INDEX__must_equal__sizeof_GX_COLOR_INDEX_TYPE
= 1/!!(ARCH_SIZEOF_GX_COLOR_INDEX == sizeof(GX_COLOR_INDEX_TYPE)) };
^
make[2]: *** [soobj/zchar1.o] Error 1
Any advice anyone?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
How does the upgrade to gcc 4.8.2 look now ? Just wondering: There is already a gcc 4.9.x series, so why are we trying to update to 4.8.x? In this branch, I've tried gcc-4.9. https://github.com/trueroad/gub/tree/gcc-4.9 I've succeed to build lilypond-installer for mingw, linux-x86, linux-64, freebsd-x86, freebsd-64 platforms. And they work fine. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
The changes from Masamichi to librestrict look safe, and the later floating-point-endless-loop-eating-all-memory should be gone now that I've re-worked the skyline merge code. If gcc 4.8.2 still looks difficult, I'll look into problem with the templates. Now, in this branch, https://github.com/trueroad/gub/tree/gcc-4.8 The following commands have been succeed by gcc-4.8.2. bin/gub mingw::lilypond-installer bin/gub linux-x86::lilypond-installer bin/gub linux-64::lilypond-installer bin/gub freebsd-x86::lilypond-installer bin/gub freebsd-64::lilypond-insatller They work fine in my environments. mingw: bad_alloc don't occur. freebsd-x86: SIGSEGV don't occur. Correct PDFs are generated. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
Phil Holmes mail at philholmes.net writes: Phil Holmes mail at philholmes.net writes: /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org-- lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' This involves the address of a function in a templated class, the behavior of which didn't get resolved until C++ defect 115 and gcc 4.5.0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407 We could probably use some other test to see if the base mark_smob() function has been redefined in the derived class ... or put the responsibility to register mark_smob() into each derived class. OK: here's the result of a grep for gnu/gcc on the GUB machine: [...] It looks like a bit of a mish-mash. But if we were going to upgrade from what is mostly gcc 4.1.1/2, which version should we go to? Phil, How does the upgrade to gcc 4.8.2 look now ? The changes from Masamichi to librestrict look safe, and the later floating-point-endless-loop-eating-all-memory should be gone now that I've re-worked the skyline merge code. If gcc 4.8.2 still looks difficult, I'll look into problem with the templates. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
How does the upgrade to gcc 4.8.2 look now ? Just wondering: There is already a gcc 4.9.x series, so why are we trying to update to 4.8.x? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, October 12, 2014 6:41 PM Subject: Re: GUB fail with smob templates Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' I've pushed a prospective fix to staging. No idea whether it will do the trick. -- David Kastrup This failed again. I've attached a zip of the whole logfile. I'll be around for most of today, so can test any potential fix quite quickly. I'll also look at how GCC could be updated. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
- Original Message - From: Phil Holmes m...@philholmes.net To: David Kastrup d...@gnu.org Cc: lilypond-devel@gnu.org Sent: Tuesday, October 14, 2014 10:03 AM Subject: Re: GUB fail with smob templates - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, October 12, 2014 6:41 PM Subject: Re: GUB fail with smob templates Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' I've pushed a prospective fix to staging. No idea whether it will do the trick. -- David Kastrup This failed again. I've attached a zip of the whole logfile. I'll be around for most of today, so can test any potential fix quite quickly. I'll also look at how GCC could be updated. -- Phil Holmes OK: here's the result of a grep for gnu/gcc on the GUB machine: specs/cross/gcc-2-95.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-2.95.3/gcc-everything-2.95.3.tar.gz' specs/cross/gcc-core.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.1/gcc-4.1.1.tar.bz2' specs/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2' specs/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.1/gcc-4.1.1.tar.bz2' specs/cygwin/cross/gcc.py:# source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2' specs/cygwin/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.3.4/gcc-4.3.4.tar.bz2' specs/cygwin/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-3.4.4/gcc-3.4.4.tar.bz2' specs/debian/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-' + debian.gcc_version + '/gcc-' + debian.gcc_version + '.tar.bz2' specs/debian/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-3.4.6/gcc-3.4.6.tar.bz2' specs/freebsd/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.3.2/gcc-4.3.2.tar.bz2' specs/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2' specs/linux-arm-softfloat/cross/gcc-core.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-3.4.6/gcc-3.4.6.tar.bz2' specs/linux-arm-softfloat/cross/gcc.py: source = 'http://ftp.gnu.org/pub/gnu/gcc/gcc-3.4.6/gcc-3.4.6.tar.bz2' It looks like a bit of a mish-mash. But if we were going to upgrade from what is mostly gcc 4.1.1/2, which version should we go to? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, October 12, 2014 6:41 PM Subject: Re: GUB fail with smob templates Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' I've pushed a prospective fix to staging. No idea whether it will do the trick. -- David Kastrup Zip attached. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/smobs.tcc:133: error: invalid operands of types 'scm_unused_struct* (Smob_baseSkyline_pair::*)()' and 'scm_unused_struct* (Skyline_pair::*)()' to binary 'operator!=' This is getting absolutely ridiculous, but I pushed another fix to staging (basically, I now have to cast a member function pointer to its own type before comparing it with another member function pointer cast to its type). With regard to upgrading gcc versions, I think that the latest 4.8 version of gcc should be a reasonably safe bet. However, I don't know whether darwin-ppc is still a supported platform for it. One would probably have to take the last supported version. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net This is getting absolutely ridiculous, but I pushed another fix to staging (basically, I now have to cast a member function pointer to its own type before comparing it with another member function pointer cast to its type). OK: I'm running patchy-staging now and will tryu again once the fix is in master. With regard to upgrading gcc versions, I think that the latest 4.8 version of gcc should be a reasonably safe bet. However, I don't know whether darwin-ppc is still a supported platform for it. One would probably have to take the last supported version. I'll do some research on the ppc and once I've tried this fix, I'll look at upgrading GUB. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Tuesday, October 14, 2014 12:16 PM Subject: Re: GUB fail with smob templates Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, October 12, 2014 6:41 PM Subject: Re: GUB fail with smob templates Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' I've pushed a prospective fix to staging. No idea whether it will do the trick. -- David Kastrup Zip attached. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/smobs.tcc:133: error: invalid operands of types 'scm_unused_struct* (Smob_baseSkyline_pair::*)()' and 'scm_unused_struct* (Skyline_pair::*)()' to binary 'operator!=' This is getting absolutely ridiculous, but I pushed another fix to staging (basically, I now have to cast a member function pointer to its own type before comparing it with another member function pointer cast to its type). Fails compiling for a different target now. Logfile attached again. /home/gub/gub/target/freebsd-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/smobs.tcc:136: error: invalid operands of types 'bool' and 'int' to binary 'operator==' So now we cannot compare a bool with an int? What is this, Pascal? The error message also does not fit the current line in smobs.tcc: 136 if (static_castSCM (Super::*)()(Super::mark_smob) != 137 static_castSCM (Super::*)()(Smob_baseSuper::mark_smob)) Previous versions had 136 if (Super::type_p_name_ != 0) which is still not the best fit, but at least there is an integer involved. Do you reckon we should continue to try to get this fixed, or just bite the bullet and update gcc and see if that works? It would appear that the versions of GCC are somewhat basic regarding their template support. Now what is really surprising to me is that 2.19.15 went ahead without much of a hitch. Because the changes of 2.19.16, as compared to 2.19.15, seem to be more on the surface. Since we _did_ get 2.19.15 through, 2.19.16 should be a breeze. However, the current batch of error messages is totally baffling to me. The current error messages just do not appear to match the flagged lines at all. So I'm poking around quite in the dark. It's probably silly to ask since you are not building for the first time, but you are sure that you are working from the current origin/release/unstable ? To me it looks like updating gcc to some newer version might make sense. Starting with version 2.19.15, we are relying more on templates than before. And working with gcc versions that go bonkers in entirely puzzling ways is likely going to cause more trouble than the one we are having right now anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Fails compiling for a different target now. Logfile attached again. /home/gub/gub/target/freebsd-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/smobs.tcc:136: error: invalid operands of types 'bool' and 'int' to binary 'operator==' So now we cannot compare a bool with an int? What is this, Pascal? The error message also does not fit the current line in smobs.tcc: 136 if (static_castSCM (Super::*)()(Super::mark_smob) != 137 static_castSCM (Super::*)()(Smob_baseSuper::mark_smob)) Previous versions had 136 if (Super::type_p_name_ != 0) which is still not the best fit, but at least there is an integer involved. I agree with what you say about the strange error message. Just to confirm, though: lines 136-7 as given in the error message are the lines to be found in smobs.tcc. Do you reckon we should continue to try to get this fixed, or just bite the bullet and update gcc and see if that works? It would appear that the versions of GCC are somewhat basic regarding their template support. Now what is really surprising to me is that 2.19.15 went ahead without much of a hitch. Because the changes of 2.19.16, as compared to 2.19.15, seem to be more on the surface. Since we _did_ get 2.19.15 through, 2.19.16 should be a breeze. However, the current batch of error messages is totally baffling to me. The current error messages just do not appear to match the flagged lines at all. So I'm poking around quite in the dark. It's probably silly to ask since you are not building for the first time, but you are sure that you are working from the current origin/release/unstable ? Had me worried. I checked and I am. To me it looks like updating gcc to some newer version might make sense. Starting with version 2.19.15, we are relying more on templates than before. And working with gcc versions that go bonkers in entirely puzzling ways is likely going to cause more trouble than the one we are having right now anyway. I'll start looking at it now. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail with smob templates
GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Stencil::*)()' and 'scm_unused_struct* (Smob_baseStencil::*)()' to binary 'operator!=' make[1]: *** [out/arpeggio.o] Error 1 /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Translator::*)()' and 'scm_unused_struct* (Smob_baseTranslator::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Translator::*)()' and 'scm_unused_struct* (Smob_baseTranslator::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Prob::*)()' and 'scm_unused_struct* (Smob_baseProb::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Prob::*)()' and 'scm_unused_struct* (Smob_baseProb::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Pitch::*)()' and 'scm_unused_struct* (Smob_basePitch::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Translator::*)()' and 'scm_unused_struct* (Smob_baseTranslator::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Prob::*)()' and 'scm_unused_struct* (Smob_baseProb::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob_array::*)()' and 'scm_unused_struct* (Smob_baseGrob_array::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Stencil::*)()' and 'scm_unused_struct* (Smob_baseStencil::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Prob::*)()' and 'scm_unused_struct* (Smob_baseProb::*)()' to binary 'operator!=' make[1]: *** [out/arpeggio-engraver.o] Error 1 make[1]: *** [out/articulations.o] Error 1 /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Prob::*)()' and
Re: GUB fail with smob templates
Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' What a crock. Do we have a reasonably fast way to get to these error messages? I can apply a patch trying to get across this error message (and its relatives), but I don't really know whether it will do the trick with the old gcc version we appear to be using here. Or is there a reasonable chance of moving GUB to a newer version of GCC? I think we are older than most C++ compilers by now. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' I've pushed a prospective fix to staging. No idea whether it will do the trick. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
I'll try to see whether this is successful tomorrow afternoon. -- Phil Holmes - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, October 12, 2014 6:41 PM Subject: Re: GUB fail with smob templates Phil Holmes m...@philholmes.net writes: GUB has again coughed on the changes to the SMOB code. It's well out of my depth to understand why, but I've pasted below some of the error messages: the make is built with -j14, so I presume that's why there are so many. /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' I've pushed a prospective fix to staging. No idea whether it will do the trick. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB fail with smob templates
GUB failed today with the following errors: /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh: In static member function 'static scm_unused_struct* Unpure_pure_container::make_smob (scm_unused_struct*, scm_unused_struct*)': /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:39: error: 'templateclass Super class Smob2' used without template parameters /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:40: error: 'templateclass Super class Smob2' used without template parameters I assume this is http://code.google.com/p/lilypond/issues/detail?id=4082 but it's way over my head to know what the problem is. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
Phil Holmes m...@philholmes.net writes: GUB failed today with the following errors: /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh: In static member function 'static scm_unused_struct* Unpure_pure_container::make_smob (scm_unused_struct*, scm_unused_struct*)': /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:39: error: 'templateclass Super class Smob2' used without template parameters /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:40: error: 'templateclass Super class Smob2' used without template parameters I assume this is http://code.google.com/p/lilypond/issues/detail?id=4082 The actually flagged code is in issue 4086 instead, though 4086 heavily depends on 4082. but it's way over my head to know what the problem is. Possibly an older gcc version. Are these the only errors? In a parallel build, one would expect to run across several errors in different files before compilation bombs out. Would be good to know and/or have some further complaints to look at. I'll try brooding over the error messages and see whether they suggest some syntax that might be more palatable to older gcc versions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: GUB failed today with the following errors: /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh: In static member function 'static scm_unused_struct* Unpure_pure_container::make_smob (scm_unused_struct*, scm_unused_struct*)': /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:39: error: 'templateclass Super class Smob2' used without template parameters /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:40: error: 'templateclass Super class Smob2' used without template parameters I assume this is http://code.google.com/p/lilypond/issues/detail?id=4082 The actually flagged code is in issue 4086 instead, though 4086 heavily depends on 4082. but it's way over my head to know what the problem is. Possibly an older gcc version. Are these the only errors? In a parallel build, one would expect to run across several errors in different files before compilation bombs out. Would be good to know and/or have some further complaints to look at. I'll try brooding over the error messages and see whether they suggest some syntax that might be more palatable to older gcc versions. Pushed a matching fix. It does not appear that this particular problem is coded elsewhere. I think that the compiler complaint might be correct even though my newer GCC variant does not bother mentioning it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, September 14, 2014 4:50 PM Subject: Re: GUB fail with smob templates David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: GUB failed today with the following errors: /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh: In static member function 'static scm_unused_struct* Unpure_pure_container::make_smob (scm_unused_struct*, scm_unused_struct*)': /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:39: error: 'templateclass Super class Smob2' used without template parameters /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git- release-unstable/lily/include/unpure-pure-container.hh:40: error: 'templateclass Super class Smob2' used without template parameters I assume this is http://code.google.com/p/lilypond/issues/detail?id=4082 The actually flagged code is in issue 4086 instead, though 4086 heavily depends on 4082. but it's way over my head to know what the problem is. Possibly an older gcc version. Are these the only errors? In a parallel build, one would expect to run across several errors in different files before compilation bombs out. Would be good to know and/or have some further complaints to look at. I'll try brooding over the error messages and see whether they suggest some syntax that might be more palatable to older gcc versions. Pushed a matching fix. It does not appear that this particular problem is coded elsewhere. I think that the compiler complaint might be correct even though my newer GCC variant does not bother mentioning it. I'll run patchy-staging and try to restart GUB. Unlikely there will be an upload today, though: likely I'll go tomorrow. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
