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
Dan Eble dan at faithful.be writes:
On Dec 8, 2014, at 08:21 , David Kastrup dak at gnu.org wrote:
Masamichi HOSODA trueroad at sea.plala.or.jp writes:
I agree that changing the algorithms is preferred; I didn’t mean to
suggest otherwise. But if that’s not going to happen
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
Masamichi HOSODA truer...@sea.plala.or.jp writes:
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
On Dec 8, 2014, at 08:21 , David Kastrup d...@gnu.org wrote:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
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
Dan Eble d...@faithful.be writes:
On Dec 5, 2014, at 06:22 , David Kastrup d...@gnu.org wrote:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Therefore, robust treating for margin of error is necessary.
That does not help all that much: it just shifts the problem somewhere
else. It
On Dec 6, 2014, at 09:12 , David Kastrup d...@gnu.org wrote:
Dan Eble d...@faithful.be writes:
I’ve only skimmed some web pages on this subject, but if the following
can be tolerated, it seems like the simplest way to reduce pain in
short order:
On more modern x86 processors that
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Also, the mention of optimization reminds me of one of the horrors
of floating point types: a value in a register can quietly be
changed when it is written to memory. Take a look at some of the
“myths” in section 1 of
On Dec 5, 2014, at 06:22 , David Kastrup d...@gnu.org wrote:
Masamichi HOSODA truer...@sea.plala.or.jp writes:
Therefore, robust treating for margin of error is necessary.
That does not help all that much: it just shifts the problem somewhere
else. It will tend to fix known test cases
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
On Dec 4, 2014, at 09:58 , Masamichi HOSODA truer...@sea.plala.or.jp wrote:
Also, the mention of optimization reminds me of one of the horrors of
floating point types: a value in a register can quietly be changed when it
is written to memory. Take a look at some of the “myths” in section 1
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
On Dec 3, 2014, at 07:37 , Masamichi HOSODA truer...@sea.plala.or.jp wrote:
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.
On Dec 4, 2014, at 00:12 , Dan Eble d...@faithful.be wrote:
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
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:
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
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:
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
David Kastrup wrote Monday, December 01, 2014 3:25 PM
I thought that I had at one time proposed something to be changed (as
part of some issue?) order to deal with possible memory corruption, but
a quick look through the log messages does not turn up either a commit
from me or a commit
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Monday, December 01, 2014 3:25 PM
I thought that I had at one time proposed something to be changed (as
part of some issue?) order to deal with possible memory corruption, but
a quick look through the log messages does not turn
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 }
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 }
On Sun, Oct 26, 2014 at 9:41 AM, Phil Holmes m...@philholmes.net wrote:
- Original Message - From: Phil Holmes m...@philholmes.net
To: Federico Bruni fedel...@gmail.com
Cc: lilypond-devel@gnu.org
Sent: Saturday, October 25, 2014 3:39 PM
Subject: Re: GUB and mpfr/mpc
It's my
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
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 }
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.
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
, October 28, 2014 12:58 PM
Subject: Re: GUB and mpfr/mpc
Phil Holmes writes:
If there's nothing in the log file, you'll have to investigate by
hand.
Go to the build directory and see
cd /home/gub/gub/target/tools/build/librestrict-1.9.a
gcc -W -Wall -fno-stack-protector -I. -fPIC
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
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
Phil Holmes writes:
https://github.com/gperciva/gub
I don't think librestrict has changed in years, works for me [on 14.10].
Jan
$ ./bin/gub tools::librestrict
calculating dependencies
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc librestrict make libtool file tar m4 perl
Jan Nieuwenhuizen jann...@gnu.org writes:
Phil Holmes writes:
https://github.com/gperciva/gub
I don't think librestrict has changed in years, works for me [on 14.10].
Huh. Both of you on the same side of 32/64 bit?
--
David Kastrup
___
- Original Message -
From: David Kastrup d...@gnu.org
To: Jan Nieuwenhuizen jann...@gnu.org
Cc: Phil Holmes m...@philholmes.net; Federico Bruni
fedel...@gmail.com; lilypond-devel@gnu.org
Sent: Tuesday, October 28, 2014 10:58 AM
Subject: Re: GUB and mpfr/mpc
Jan Nieuwenhuizen jann
Holmes m...@philholmes.net
Cc: David Kastrup d...@gnu.org; Federico Bruni fedel...@gmail.com;
lilypond-devel@gnu.org
Sent: Tuesday, October 28, 2014 10:45 AM
Subject: Re: GUB and mpfr/mpc
Phil Holmes writes:
https://github.com/gperciva/gub
I don't think librestrict has changed in years, works
On Oct 28, 2014, at 07:25 , Phil Holmes m...@philholmes.net wrote:
Tail of target/tools/log/librestrict.log
./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
buf-__unused5 = 0;
^
What *is* in the structure? Could there be something ridiculous like #define
unused
Subject: Re: GUB and mpfr/mpc
Phil Holmes writes:
https://github.com/gperciva/gub
I don't think librestrict has changed in years, works for me [on 14.10].
Jan
$ ./bin/gub tools::librestrict
calculating dependencies
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc
Phil Holmes writes:
Mine is 32 bit in a VM.
I'm on 64 bit iron -- however, this hasn't changed in years. Possibly
a weird include path that does not use the local kernel_stat.h but
takes it fro somewhere else?
Jan
--
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org
28, 2014 12:58 PM
Subject: Re: GUB and mpfr/mpc
Phil Holmes writes:
If there's nothing in the log file, you'll have to investigate by hand.
Go to the build directory and see
cd /home/gub/gub/target/tools/build/librestrict-1.9.a
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
- Original Message -
From: Jan Nieuwenhuizen jann...@gnu.org
What repository are you using?
Greetings, Jan
https://github.com/gperciva/gub
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
- Original Message -
From: Phil Holmes m...@philholmes.net
To: Federico Bruni fedel...@gmail.com
Cc: lilypond-devel@gnu.org
Sent: Saturday, October 25, 2014 3:39 PM
Subject: Re: GUB and mpfr/mpc
It's my computer (or strictly, a VM on my computer).
So it would appear that in order
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: Phil Holmes m...@philholmes.net
To: Federico Bruni fedel...@gmail.com
Cc: lilypond-devel@gnu.org
Sent: Saturday, October 25, 2014 3:39 PM
Subject: Re: GUB and mpfr/mpc
It's my computer (or strictly, a VM on my
David Kastrup writes:
OK - I've downloaded 14.04, installed it in a VM, updated it,
installed git, cloned GUB and run make bootstrap. I get:
building package: tools::librestrict
*** Stage: download (librestrict, tools)
*** Stage: untar (librestrict, tools)
*** Stage: patch (librestrict,
- 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 getting
- 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
- 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
- Original Message -
From: Masamichi HOSODA truer...@sea.plala.or.jp
libgmp-dev package exists after Ubuntu 12.04.
http://packages.ubuntu.com/search?keywords=libgmp-devsearchon=namessuite=allsection=all
My environment is Ubuntu 14.04LTS amd64.
Are you using Ubuntu 10.04?
Afraid so.
Il giorno sab 25 ott 2014 alle 17:18, Phil Holmes m...@philholmes.net
ha scritto:
- Original Message - From: Masamichi HOSODA
truer...@sea.plala.or.jp
libgmp-dev package exists after Ubuntu 12.04.
http://packages.ubuntu.com/search?keywords=libgmp-devsearchon=namessuite=all§ion=all
My
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: Masamichi HOSODA truer...@sea.plala.or.jp
libgmp-dev package exists after Ubuntu 12.04.
http://packages.ubuntu.com/search?keywords=libgmp-devsearchon=namessuite=allsection=all
My environment is Ubuntu 14.04LTS
: Masamichi HOSODA ; lilypond-devel@gnu.org
Sent: Saturday, October 25, 2014 4:34 PM
Subject: Re: GUB and mpfr/mpc
Il giorno sab 25 ott 2014 alle 17:18, Phil Holmes m...@philholmes.net ha
scritto:
- Original Message - From: Masamichi HOSODA
truer...@sea.plala.or.jp
libgmp
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'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
appears
Phil Holmes m...@philholmes.net writes:
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
54 matches
Mail list logo
