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,
The principle with GUB is that it has details of all the packages it uses,
and by issuing the 'make bootstrap' command, it goes and gets all the
packages it needs, and all their dependencies, and builds them all from
scratch. The problem I believe I now have is that gcc 4.8 has a new
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,
When environment variable PATH is undefined, the following error occurs.
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binset PATH=
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binlilypond
GNU LilyPond 2.19.16
terminate called after throwing an instance of 'std::logic_error'
what():
Converting to `./test.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
-dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=./test.pdf
-c.setpdfwrite -ftest.ps)' failed (139)
fatal error: failed files: test.ly
I've seen a proposed patch from Masamichi, but as David says, this may
fix the issue but doesn't shed any light on what is the root cause.
Is it worth trying to go back to an earlier version of gcc? If so,
how would I go about that?
I lean towards just using Masamichi's patch.
I'll pull
I agree that changing the algorithms is preferred; I didn’t mean to suggest
otherwise. But if that’s not going to happen overnight, and there is a way
to mitigate the problem in the meantime without touching the code, the people
affected would value it.
I tried -mfpmath=sse -msse2.
It
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when
There is this at the end of skyline.cc:
// Should add during ver2.19 (to avoid an endless loop
// when merging identical skylines with a vertical segment)
// if (end = s2-front().end_) s2-pop_front();
I meant at the end of internal_merge_skyline() in skyline.cc. (Fatigue
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when
,
the result was that correct PDF was generated.
The source tree when succeeding, is as follows.
https://github.com/trueroad/gub/commit/5e63dbde436bd3fca154557672394987c8d2e385
Masamichi Hosoda
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
In mingw, lilypond crashes as follows.
Does someone know this reason?
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bintype test.ly
{ c d e f g a b }
C:\tmp\lilypond-2.19.16-0
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
In mingw, lilypond crashes as follows.
Does someone know this reason?
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bintype test.ly
{ c d e f g a b }
C:\tmp\lilypond-2.19.16-0
Masamichi HOSODA truer...@sea.plala.or.jp writes:
In mingw, lilypond crashes as follows.
Does someone know this reason?
```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bintype test.ly
{ c d e f g a b }
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binlilypond test.ly
GNU LilyPond
I've succeeded to build lilypond for the following targets by gcc-4.8.2.
linux-x86
linux-64
freebsd-x86
freebsd-64
mingw
(I don't build lilypond for darwin environments because I don't have them.)
My building environment is Ubuntu 14.04 LTS 64 bit.
I use the following gub repository.
How about this patch?
--- librestrict/xstatconv.c.org 2014-10-19 09:52:52.951262300 +0900
+++ librestrict/xstatconv.c 2014-11-01 20:26:35.734854500 +0900
@@ -48,20 +48,16 @@
{
struct stat *buf = ubuf;
+ /* zero clear */
+ memset(buf, 0, sizeof(*buf));
/*
Masamichi HOSODA truer...@sea.plala.or.jp writes:
How about this patch?
--- librestrict/xstatconv.c.org 2014-10-19 09:52:52.951262300 +0900
+++ librestrict/xstatconv.c 2014-11-01 20:26:35.734854500 +0900
@@ -48,20 +48,16 @@
{
struct stat *buf = ubuf;
+/* zero
- Original Message -
From: Masamichi HOSODA truer...@sea.plala.or.jp
To: lilypond-devel@gnu.org
Sent: Thursday, October 23, 2014 12:07 PM
Subject: Re: GUB and mpfr/mpc
I'm trying to update GCC on GUB and have a new virtual machine with
updated versions. I was having problems
- Original Message -
From: Masamichi HOSODA truer...@sea.plala.or.jp
To: m...@philholmes.net
Cc: lilypond-devel@gnu.org; truer...@sea.plala.or.jp
Sent: Saturday, October 25, 2014 2:58 PM
Subject: Re: GUB and mpfr/mpc
- Original Message -
From: Masamichi HOSODA truer
I'm trying to update GCC on GUB and have a new virtual machine with
updated versions. I was having problems getting MPFR to build, but it
looks like I'ev fixed that with the new VM. However, it looks to me like
GCC 4.8.2 has a new dependency on MPC that older versions did not: there
I am interested in lilypad (Windows) development.
Thank you for merging my pull requests.
I've updated the CG with what I believe are the correct steps for
developments to LilyPad. The new text is in master, but not yet on the
website. I'd be interested in comments from anyone with
Message-ID: 40A388970C6540E08618DFC1C4932F1E@Advent
Now with the attachment :-(
--
Phil Holmes
- Original Message -
From: Phil Holmes m...@philholmes.net
To: lilypond-devel@gnu.org; Masamichi Hosoda
truer...@sea.plala.or.jp
Sent: Friday, September 05, 2014 1:19 PM
Subject: Re
it.
It is better to run make clean, before building lilypad.exe.
Otherwise, ANSI version objects may be mixed to UNICODE version lilypad.exe.
From: Masamichi HOSODA truer...@sea.plala.or.jp
Subject Re: lilypad.exe Japanese resource (menu, dialog, etc.)
Date Fri, 05 Sep 2014 22:45:42 +0900 (JST
Hi.
Japanese resource (menu, dialog, etc.) of
official pre-built lilypad.exe is broken.
I installed lilypond-2.19.13-1.mingw.exe
(download from
http://download.linuxaudio.org/lilypond/binaries/mingw/lilypond-2.19.13-1.mi
ngw.exe)
and started lilypad.exe.
Then, all the Japanese character strings
- Original Message -
From: Phil Holmes m...@philholmes.net
To: lilypond-devel@gnu.org; Masamichi Hosoda
truer...@sea.plala.or.jp
Sent: Friday, September 05, 2014 1:19 PM
Subject: Re: lilypad.exe Japanese resource (menu, dialog, etc.)
- Original Message -
From: Masamichi
201 - 226 of 226 matches
Mail list logo
