Re: GUB and mpfr/mpc

[Masamichi Hosoda]

> >>> 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"
> >> 
> >> That's a SIGSEGV.  Not something that a GhostScript executable should be
> >> throwing.  Could it be that the 64-bit cross compilation causes
> >> problems?
> >
> > I tried on 32-bit FreeBSD.
> > The result was just similar.
> > I tried to execute gs directly.
> > Then Segmentation fault (core dumped) happened.
> >
> > linux-x86 binary that I built seems no problem.
> > I think that it's no problem even if 32-bit binary
> > is cross compiled by the 64-bit environment.
> 
> No idea.  Phil, what is your experience with that?

I tried to update freebsd-x86::freebsd-runtime from 4.11 to 6.2.
(It becomes same version as freebsd-64::freebsd-runtime.)

https://github.com/trueroad/gub/tree/gcc-4.8

And, I executed 'lilypond test.ly' on 32-bit FreeBSD.
Then SIGSEGV didn't occur and correct pdf was generated.

I think FreeBSD 4.11 is too old.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Keith OHara]

Dan Eble  faithful.be> writes:

> > On Dec 8, 2014, at 08:21 , David Kastrup  gnu.org> wrote:
> > 
> > Masamichi HOSODA  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 would value it.
> >> 
> >> I tried "-mfpmath=sse -msse2".
> >> It worked fine. bad_alloc didn't occur.
> >> Correct PDF was generated.
> >> 
> >> It can be a workaround until changing the algorithms.
> > 
> > It's not architecture independent.  And may blow up for other reasons.
> 
> But it’s good to know that the problem was floating point and not memory 
corruption, so thanks for testing it.
> 

This sounds like the runaway-loop problem we noticed when allowing
zero-width items into skylines.   I opened issue 4229 and will post
a patch.




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

> On Dec 8, 2014, at 08:21 , David Kastrup  wrote:
> 
> Masamichi HOSODA  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 would value it.
>> 
>> I tried "-mfpmath=sse -msse2".
>> It worked fine. bad_alloc didn't occur.
>> Correct PDF was generated.
>> 
>> It can be a workaround until changing the algorithms.
> 
> It's not architecture independent.  And may blow up for other reasons.

But it’s good to know that the problem was floating point and not memory 
corruption, so thanks for testing it.
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  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 would value it.
>
> I tried "-mfpmath=sse -msse2".
> It worked fine. bad_alloc didn't occur.
> Correct PDF was generated.
>
> It can be a workaround until changing the algorithms.

It's not architecture independent.  And may blow up for other reasons.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> 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 worked fine. bad_alloc didn't occur.
Correct PDF was generated.

It can be a workaround until changing the algorithms.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

On Dec 6, 2014, at 09:12 , David Kastrup  wrote:
> 
> Dan Eble  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 support SSE2, specifying
>>the compiler options -mfpmath=sse -msse2 ensures all float
>>and double operations are performed in SSE registers and
>>correctly rounded.
>>[https://gcc.gnu.org/wiki/FloatingPointMath]
>> 
>> It worked for my example program.
> 
> "It will tend to fix known test cases and create a new set of previously
> working failures”.
[…]
> I think there is a less architecture-dependent option that keeps gcc
> from using any extra precision for intermediate results but it may be
> somewhat expensive.  On the other hand, numerics are not where LilyPond
> spends most of its time.
> 
> Probably
> 
> '-ffloat-store’
[…]
> would do the trick.  But we really rather should try to become
> independent from exact equalities as algorithm terminators.

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 saw -ffloat-store too, but I didn’t recommend it because "-ffloat-store will 
not suffice” for specific versions of GCC [1]; and "this option does not force 
unnamed temporaries to be flushed to memory, as shown by experiments” [2].  So, 
maybe it would help, to some extent, with the right compiler; or maybe there 
are no unnamed temporaries that really matter and everything will work.  If you 
don’t want to require SSE2, it's worth a try.

[1] http://christian-seiler.de/projekte/fpmath/
[2] https://hal.archives-ouvertes.fr/hal-00128124/en/
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Dan Eble  writes:

> On Dec 5, 2014, at 06:22 , David Kastrup  wrote:
>> 
>> Masamichi HOSODA  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 and create a new set of
>> previously working failures.
>> 
>> Instead the algorithms have to be rewritten in a manner where their
>> termination does not depend on the reproducibility of floating point
>> operations.  There have been a few attempts of rewriting skyline code
>> that have fixed/created some problems without any real insights into
>> what caused the fix and what caused the new problems.
>
> 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 support SSE2, specifying
> the compiler options -mfpmath=sse -msse2 ensures all float
> and double operations are performed in SSE registers and
> correctly rounded.
> [https://gcc.gnu.org/wiki/FloatingPointMath]
>
> It worked for my example program.

"It will tend to fix known test cases and create a new set of previously
working failures".

I think there is a less architecture-dependent option that keeps gcc
from using any extra precision for intermediate results but it may be
somewhat expensive.  On the other hand, numerics are not where LilyPond
spends most of its time.

Probably

'-ffloat-store'
 Do not store floating-point variables in registers, and inhibit
 other options that might change whether a floating-point value is
 taken from a register or memory.

 This option prevents undesirable excess precision on machines such
 as the 68000 where the floating registers (of the 68881) keep more
 precision than a 'double' is supposed to have.  Similarly for the
 x86 architecture.  For most programs, the excess precision does
 only good, but a few programs rely on the precise definition of
 IEEE floating point.  Use '-ffloat-store' for such programs, after
 modifying them to store all pertinent intermediate computations
 into variables.

would do the trick.  But we really rather should try to become
independent from exact equalities as algorithm terminators.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

On Dec 5, 2014, at 06:22 , David Kastrup  wrote:
> 
> Masamichi HOSODA  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 and create a new set of
> previously working failures.
> 
> Instead the algorithms have to be rewritten in a manner where their
> termination does not depend on the reproducibility of floating point
> operations.  There have been a few attempts of rewriting skyline code
> that have fixed/created some problems without any real insights into
> what caused the fix and what caused the new problems.

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 support SSE2, specifying
the compiler options -mfpmath=sse -msse2 ensures all float
and double operations are performed in SSE registers and
correctly rounded.
[https://gcc.gnu.org/wiki/FloatingPointMath]

It worked for my example program.  SSE2 instructions were introduced in the 
Pentium 4.  Another source warns that those options are

often sufficient to remove the effects of extended-precision.
However, some operations (such as transcendental functions)
are not available in the SSE/SSE2 extensions and will still
be computed on the x87 FPU.
[http://www.network-theory.co.uk/docs/gccintro/gccintro_70.html]

There is also a lot of information at 
http://christian-seiler.de/projekte/fpmath/ .
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  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
>>> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
>> […]
>>> I think that floating point can be used as long as it's used correct.
>>> 
>>> operator== shouldn't be used for comparison of floating point values.
>>> operator!= shouldn't be used too.
>>> operator< and operator> may be used.
>> 
>> The issue is more complex than that.  Sit down and try this:
> [...]
>> Add looping and you’ve got fatal issues.  (And if you’re like me,
>> steam will erupt from your ears any second now...)
>
> You're right of course.
> A floating point operation has a margin of error always.
> When the optimization is different, the margin of error may be also different,
> because the bit width of floating point value is different
> in a register and a memory.
>
> 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 and create a new set of
previously working failures.

Instead the algorithms have to be rewritten in a manner where their
termination does not depend on the reproducibility of floating point
operations.  There have been a few attempts of rewriting skyline code
that have fixed/created some problems without any real insights into
what caused the fix and what caused the new problems.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

>>> 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 
>>> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
> […]
>> I think that floating point can be used as long as it's used correct.
>> 
>> operator== shouldn't be used for comparison of floating point values.
>> operator!= shouldn't be used too.
>> operator< and operator> may be used.
> 
> The issue is more complex than that.  Sit down and try this:
[...]
> Add looping and you’ve got fatal issues.  (And if you’re like me, steam will 
> erupt from your ears any second now...)

You're right of course.
A floating point operation has a margin of error always.
When the optimization is different, the margin of error may be also different,
because the bit width of floating point value is different
in a register and a memory.

Therefore, robust treating for margin of error is necessary.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

On Dec 4, 2014, at 09:58 , Masamichi HOSODA  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 of 
>> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
[…]
> I think that floating point can be used as long as it's used correct.
> 
> operator== shouldn't be used for comparison of floating point values.
> operator!= shouldn't be used too.
> operator< and operator> may be used.

The issue is more complex than that.  Sit down and try this:

#include 

int main(void)
{
  double a = 0;
  double b = 0;

  std::cin >> a;
  std::cin >> b;

  double x = a/b;
  if (x < a/b) {
std::cout << "x:" << x << " < " << (a/b) << std::endl;
  }
  volatile double y = x;
  if (y < a/b) {
std::cout << "y:" << y << " < " << (a/b) << std::endl;
  }

  return 0;
}

Results in LilyDev 3:

$ g++ fp.cc -o fp && (echo "2 3" | ./fp)
x:0.67 < 0.67
y:0.67 < 0.67

$ g++ -O3 fp.cc -o fp && (echo "2 3" | ./fp)
y:0.67 < 0.67

Add looping and you’ve got fatal issues.  (And if you’re like me, steam will 
erupt from your ears any second now...)
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

>> 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 
> strikes again.)
> 
>> make the code a lot less scaring.
> 
> scary (derp)

I tried the following patch, too.
But bad_alloc occurred.

```
--- a/lily/skyline.cc   2014-12-01 21:31:21.353083100 +0900
+++ b/lily/skyline.cc   2014-12-04 23:46:29.488379900 +0900
@@ -329,7 +329,7 @@
 s1->pop_front ();
   // 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();
+  if (end >= s2->front().end_) s2->pop_front();

   x = end;
 }
```

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

>>> 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 optimization was turned on.
> 
> 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();
> 
> 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 
> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
> 
> Do the skylines need to deal with the wide range of values that “double" 
> allows?  If not, replacing the Real class with a fixed-point math class would 
> make the code a lot less scaring.

I think that floating point can be used as long as it's used correct.

operator== shouldn't be used for comparison of floating point values.
operator!= shouldn't be used too.
operator< and operator> may be used.
It's better not to use operator<= and operator>=.

I tried the following patch.
But bad_alloc occurred.

Then, I think the floating point problem may be unrelated to this case.

```
--- a/lily/skyline.cc   2014-12-01 21:31:21.353083100 +0900
+++ b/lily/skyline.cc   2014-12-04 22:56:17.740379900 +0900
@@ -184,7 +184,7 @@

   // conceals and intersection_x involve multiplication and
   // division. Avoid that, if we can.
-  if (c.y_intercept_ == -infinity_f)
+  if ((isinf(c.y_intercept_) && signbit(c.y_intercept_)))
 {
   if (c.end_ > b.end_)
 return b.end_;
@@ -197,7 +197,7 @@
 return start_x;

   Real i = b.intersection_x (c);
-  if (i > start_x && i <= b.end_ && i <= c.end_)
+  if (i > start_x && (i - b.end_) < DBL_EPSILON && (i - c.end_) < 
DBL_EPSILON)
 return i;

   start_x = c.end_;
```

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

On Dec 4, 2014, at 00:12 , Dan Eble  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 the end of internal_merge_skyline() in skyline.cc. (Fatigue strikes 
again.)

> make the code a lot less scaring.

scary (derp)
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

On Dec 3, 2014, at 07:37 , Masamichi HOSODA  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.
>> 
>> Further, even if the runtime is mingw-w64,
>> bad_alloc occurred when optimization was turned on.

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();

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 
https://hal.archives-ouvertes.fr/hal-00128124/en/ .

Do the skylines need to deal with the wide range of values that “double" 
allows?  If not, replacing the Real class with a fixed-point math class would 
make the code a lot less scaring.
— 
Dan


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> 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 optimization was turned on.

 For both of bad_alloc prevented and optimization,
 I tried the following setting.
 Only one file (lily/skyline.cc) optimization is disabled
 and all other files optimization is enabled.
>>> 
>>> Do you have a backtrace that might give us some more clue about where
>>> lily/skyline.cc has a problem?
>>> 
>>> 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 message ringing a bell.
>>
>> I turned off optimization to get correct backtrace,
>> but bad_alloc didn't occur.
>> Therefore I could get only incomplete backtrace.
>>
>> It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc.
>> I think the problem is Skyline::internal_merge_skyline
>> and/or first_intersection.
>>
>> Skyline::internal_merge_skyline has a while loop with push_back.
>> I think that the loop termination condition may break by optimization.
> 
> I need more elements from the backtrace.  The problem most likely is
> that the Skyline is destructed before work with it is finished, and that
> means that somewhere in the call chain the Skyline is not maintained in
> a manner where the Lisp Garbage collector will consider it as still in
> use.
> 
> So internal_merge_skyline is likely only the place where things blow up,
> but the actual cause will be further up in the call chain.

Here is first backtrace.
I stopped lilypond.exe by Ctrl-C
when the memory that lilypond.exe uses was increased rapidly.
I think that it was in the infinite loop.

```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>gdb lilypond.exe
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lilypond.exe...done.
(gdb) r test.ly
Starting program: C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin\lilypond.exe 
test.ly
[New Thread 7936.0x2234]
GNU LilyPond 2.19.16
Processing `test.ly'
Parsing...
test.ly:1: warning: no \version statement found, please add

\version "2.19.16"

for future compatibility
Interpreting music...
Preprocessing graphical objects...[New Thread 7936.0x256c]

Program received signal SIGINT, Interrupt.
[Switching to Thread 7936.0x256c]
0x76cedbf6 in KERNELBASE!CtrlRoutine ()
   from C:\WINDOWS\SYSTEM32\KernelBase.dll
(gdb) bt
#0  0x76cedbf6 in KERNELBASE!CtrlRoutine ()
   from C:\WINDOWS\SYSTEM32\KernelBase.dll
#1  0x97b0d836 in ?? ()
#2  0x in ?? ()
(gdb) info thread
  Id   Target Id Frame
* 2Thread 7936.0x256c 0x76cedbf6 in KERNELBASE!CtrlRoutine ()
   from C:\WINDOWS\SYSTEM32\KernelBase.dll
  1Thread 7936.0x2234 0x77138fc0 in ntdll!RtlCompareMemoryUlong ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 7936.0x2234)]
#0  0x77138fc0 in ntdll!RtlCompareMemoryUlong ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x77138fc0 in ntdll!RtlCompareMemoryUlong ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7718f95a in ntdll!RtlFindCharInUnicodeString ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x7714dfb4 in ntdll!RtlAllocateHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x771eee08 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x7718f75a in ntdll!RtlFindCharInUnicodeString ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x7714dfb4 in ntdll!RtlAllocateHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x76889ad1 in msvcrt!malloc () from C:\WINDOWS\SYSTEM32\msvcrt.dll
#7  0x6fcbddef in operator new (sz=40)
at 
/home/gub/gub/target/mingw/src/cross/gcc-4.8.2/libstdc++-v3/libsupc++/new_op.cc:51
#8  0x0060da2d in Skyline::internal_merge_skyline(std::list >*, std::list >*, 
std::list >*) const ()
#9  0x00611495 in Skyline::padded(double) const ()
#10 0x005fb306 in Separation_item::calc_skylines(scm_unused_struct*) ()
#11 0x6bf921c0 in scm_dapply ()
   from C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin\libguile-17.dll
#12 0x000

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  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 runtime is mingw-w64,
 bad_alloc occurred when optimization was turned on.
>>>
>>> For both of bad_alloc prevented and optimization,
>>> I tried the following setting.
>>> Only one file (lily/skyline.cc) optimization is disabled
>>> and all other files optimization is enabled.
>> 
>> Do you have a backtrace that might give us some more clue about where
>> lily/skyline.cc has a problem?
>> 
>> 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 message ringing a bell.
>
> I turned off optimization to get correct backtrace,
> but bad_alloc didn't occur.
> Therefore I could get only incomplete backtrace.
>
> It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc.
> I think the problem is Skyline::internal_merge_skyline
> and/or first_intersection.
>
> Skyline::internal_merge_skyline has a while loop with push_back.
> I think that the loop termination condition may break by optimization.

I need more elements from the backtrace.  The problem most likely is
that the Skyline is destructed before work with it is finished, and that
means that somewhere in the call chain the Skyline is not maintained in
a manner where the Lisp Garbage collector will consider it as still in
use.

So internal_merge_skyline is likely only the place where things blow up,
but the actual cause will be further up in the call chain.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

>>> 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 optimization was turned on.
>>
>> For both of bad_alloc prevented and optimization,
>> I tried the following setting.
>> Only one file (lily/skyline.cc) optimization is disabled
>> and all other files optimization is enabled.
> 
> Do you have a backtrace that might give us some more clue about where
> lily/skyline.cc has a problem?
> 
> 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 message ringing a bell.

I turned off optimization to get correct backtrace,
but bad_alloc didn't occur.
Therefore I could get only incomplete backtrace.

It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc.
I think the problem is Skyline::internal_merge_skyline
and/or first_intersection.

Skyline::internal_merge_skyline has a while loop with push_back.
I think that the loop termination condition may break by optimization.

So, I tried to disable optimization only not one file whole, but one function.

In the case of Skyline::internal_merge_skyline, the result was bad_alloc.
In the case of first_intersection,
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://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

"Trevor Daniels"  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 up either a commit
>> from me or a commit message ringing a bell.
>
> Is this worth a look?
>
> de75ed87c50519b702a936512df0a665686a59d8
> Author: Joe Neeman   2012-07-22 15:24:34
> Committer: Joe Neeman   2012-07-22 15:24:34
> Follows: release/2.15.41-1
> Precedes: 
>
> Fix memory corruption bug in skyline.

Does not look related to optimization to me.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Trevor Daniels]

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 message ringing a bell.

Is this worth a look?

de75ed87c50519b702a936512df0a665686a59d8
Author: Joe Neeman   2012-07-22 15:24:34
Committer: Joe Neeman   2012-07-22 15:24:34
Follows: release/2.15.41-1
Precedes: 

Fix memory corruption bug in skyline.

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  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 runtime is mingw-w64,
>> bad_alloc occurred when optimization was turned on.
>
> For both of bad_alloc prevented and optimization,
> I tried the following setting.
> Only one file (lily/skyline.cc) optimization is disabled
> and all other files optimization is enabled.

Do you have a backtrace that might give us some more clue about where
lily/skyline.cc has a problem?

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 message ringing a bell.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> 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 optimization was turned on.

For both of bad_alloc prevented and optimization,
I tried the following setting.
Only one file (lily/skyline.cc) optimization is disabled
and all other files optimization is enabled.

https://github.com/trueroad/gub/tree/mingw-optimize-test

Then bad_alloc didn't occur and correct PDF was generated.
However, I used gcc-4.9.3 because gcc-4.8.2 was Segmentation Fault.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

>> Masamichi HOSODA  writes:
>> 
 Masamichi HOSODA  writes:
 
> In mingw, lilypond crashes as follows. 
> Does someone know this reason? 
>
> ```
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
> { c d e f g a b }
>
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
> GNU LilyPond 2.19.16
> Processing `test.ly'
> Parsing...
> test.ly:1: warning: no \version statement found, please add
>
> \version "2.19.16"
>
> for future compatibility
> Interpreting music...
> Preprocessing graphical objects...terminate called after throwing an 
> instance of
>  'std::bad_alloc'
>   what():  std::bad_alloc
 
 No idea.  Looks like out of memory.
>>>
>>> I also think so.
>>> I look at the task manager.
>>> The memory that lilypond.exe uses is increased rapidly.
>>> Then, lilypond.exe crashes at about 2 GB.
>>>
>>> My Windows environment is 64-bit. The memory is quite larger than 2 GB.
>>> I think that something continues demanding a memory by an infinite loop.
>>> Then, lilyond.exe crashes, when the 32-bit process memory limit is exceeded.
>> 
>> My guess would have been that garbage collection is broken on the
>> platform, but even without collecting garbage, I should think that 2GB
>> should be sufficient for getting a small file like that compiled.
> 
> I turned off compilation optimization of mingw::lilypond as follows.
> https://github.com/trueroad/gub/commit/1a6bc45fc00fa326270f2be40a5f588083e9db75
> 
> As a result, std::bad_alloc didn't occur any more.
> But it was the following error.
> 
> ```
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
> GNU LilyPond 2.19.16
> Processing `test.ly'
> Parsing...
> test.ly:1: warning: no \version statement found, please add
> 
> \version "2.19.16"
> 
> for future compatibility
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `test.ps'...
> Converting to `./test.pdf'...
> warning: `(gs -q -dNOSAFER -dDEVICEWIDTHPOINTS=-0.00 
> -dDEVICEHEIGHTPOINTS=-0.00
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
> -sOutputFile
> =./test.pdf -c.setpdfwrite -ftest.ps)' failed (1)
> 
> programming error: Parsed object should be dead: #
> continuing, cross fingers
> programming error: Parsed object should be dead: # Prob(
> (Y-offset . 1.0) (system-grob . #) (staff-refpoint-extent 
> -3.776 .
>  -3.776) (last-in-score . #t) (page-turn-penalty) (page-break-penalty) 
> (page-tur
> n-permission . allow) (page-break-permission . allow) (vertical-skylines . 
> # line_pair>) (stencil . #))() >
> 
> continuing, cross fingers
> fatal error: failed files: "test.ly"
> 
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>
> ```
> 
> test.ps lilypond generated was broken.
> test.pdf was also broken of course.

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 optimization was turned on.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> Masamichi HOSODA  writes:
> 
>>> Masamichi HOSODA  writes:
>>> 
 In mingw, lilypond crashes as follows. 
 Does someone know this reason? 

 ```
 C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
 { c d e f g a b }

 C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
 GNU LilyPond 2.19.16
 Processing `test.ly'
 Parsing...
 test.ly:1: warning: no \version statement found, please add

 \version "2.19.16"

 for future compatibility
 Interpreting music...
 Preprocessing graphical objects...terminate called after throwing an 
 instance of
  'std::bad_alloc'
   what():  std::bad_alloc
>>> 
>>> No idea.  Looks like out of memory.
>>
>> I also think so.
>> I look at the task manager.
>> The memory that lilypond.exe uses is increased rapidly.
>> Then, lilypond.exe crashes at about 2 GB.
>>
>> My Windows environment is 64-bit. The memory is quite larger than 2 GB.
>> I think that something continues demanding a memory by an infinite loop.
>> Then, lilyond.exe crashes, when the 32-bit process memory limit is exceeded.
> 
> My guess would have been that garbage collection is broken on the
> platform, but even without collecting garbage, I should think that 2GB
> should be sufficient for getting a small file like that compiled.

I turned off compilation optimization of mingw::lilypond as follows.
https://github.com/trueroad/gub/commit/1a6bc45fc00fa326270f2be40a5f588083e9db75

As a result, std::bad_alloc didn't occur any more.
But it was the following error.

```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
GNU LilyPond 2.19.16
Processing `test.ly'
Parsing...
test.ly:1: warning: no \version statement found, please add

\version "2.19.16"

for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test.ps'...
Converting to `./test.pdf'...
warning: `(gs -q -dNOSAFER -dDEVICEWIDTHPOINTS=-0.00 -dDEVICEHEIGHTPOINTS=-0.00
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile
=./test.pdf -c.setpdfwrite -ftest.ps)' failed (1)

programming error: Parsed object should be dead: #
continuing, cross fingers
programming error: Parsed object should be dead: #) (staff-refpoint-extent -3.776 .
 -3.776) (last-in-score . #t) (page-turn-penalty) (page-break-penalty) (page-tur
n-permission . allow) (page-break-permission . allow) (vertical-skylines . #) (stencil . #))() >

continuing, cross fingers
fatal error: failed files: "test.ly"

C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>
```

test.ps lilypond generated was broken.
test.pdf was also broken of course.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Jeremiah Benham]

On Sun, Oct 26, 2014 at 9:41 AM, Phil Holmes  wrote:

> - Original Message - From: "Phil Holmes" 
> To: "Federico Bruni" 
> Cc: 
> 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 to use a current version of gcc, I need
>> at least 12.04 and I might as well go to 14.04 in order to build GUB?
>>
>> --
>> Phil Holmes
>>
>
> 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, tools)
> *** Stage: shadow (librestrict, tools)
> *** Stage: compile (librestrict, tools)
> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a &&
> gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c
>
> Tail of target/tools/log/librestrict.log >>>>>>>>
> ./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
> buf->__unused5 = 0;
> ^
> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a &&
> gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c
> <<<<<<<< Tail of target/tools/log/librestrict.log
>
> *** Failed target: tools::librestrict
> make: *** [bootstrap-git] Error 1
>
> Anyone know why?
>
>
My build is also stops here with the same error. I am on Ubuntu 14.04 on a
32 bit intel system.

Jeremiah


> --
> Phil Holmes
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  writes:

>> Masamichi HOSODA  writes:
>> 
>>> In mingw, lilypond crashes as follows. 
>>> Does someone know this reason? 
>>>
>>> ```
>>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
>>> { c d e f g a b }
>>>
>>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
>>> GNU LilyPond 2.19.16
>>> Processing `test.ly'
>>> Parsing...
>>> test.ly:1: warning: no \version statement found, please add
>>>
>>> \version "2.19.16"
>>>
>>> for future compatibility
>>> Interpreting music...
>>> Preprocessing graphical objects...terminate called after throwing an 
>>> instance of
>>>  'std::bad_alloc'
>>>   what():  std::bad_alloc
>> 
>> No idea.  Looks like out of memory.
>
> I also think so.
> I look at the task manager.
> The memory that lilypond.exe uses is increased rapidly.
> Then, lilypond.exe crashes at about 2 GB.
>
> My Windows environment is 64-bit. The memory is quite larger than 2 GB.
> I think that something continues demanding a memory by an infinite loop.
> Then, lilyond.exe crashes, when the 32-bit process memory limit is exceeded.

My guess would have been that garbage collection is broken on the
platform, but even without collecting garbage, I should think that 2GB
should be sufficient for getting a small file like that compiled.

>>> 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"
>> 
>> That's a SIGSEGV.  Not something that a GhostScript executable should be
>> throwing.  Could it be that the 64-bit cross compilation causes
>> problems?
>
> I tried on 32-bit FreeBSD.
> The result was just similar.
> I tried to execute gs directly.
> Then Segmentation fault (core dumped) happened.
>
> linux-x86 binary that I built seems no problem.
> I think that it's no problem even if 32-bit binary
> is cross compiled by the 64-bit environment.

No idea.  Phil, what is your experience with that?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> Masamichi HOSODA  writes:
> 
>> In mingw, lilypond crashes as follows. 
>> Does someone know this reason? 
>>
>> ```
>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
>> { c d e f g a b }
>>
>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
>> GNU LilyPond 2.19.16
>> Processing `test.ly'
>> Parsing...
>> test.ly:1: warning: no \version statement found, please add
>>
>> \version "2.19.16"
>>
>> for future compatibility
>> Interpreting music...
>> Preprocessing graphical objects...terminate called after throwing an 
>> instance of
>>  'std::bad_alloc'
>>   what():  std::bad_alloc
> 
> No idea.  Looks like out of memory.

I also think so.
I look at the task manager.
The memory that lilypond.exe uses is increased rapidly.
Then, lilypond.exe crashes at about 2 GB.

My Windows environment is 64-bit. The memory is quite larger than 2 GB.
I think that something continues demanding a memory by an infinite loop.
Then, lilyond.exe crashes, when the 32-bit process memory limit is exceeded.

>> In freebsd-x86, gs fails as follows.
>> (I tested this on 64bit FreeBSD. Perhaps it may succeed on 32bit FreeBSD.)
>>
>> ```
>> $ cat test.ly
>> { c d e f g a b }
>>
>> $ ./lilypond test.ly
>> GNU LilyPond 2.19.16
>> Processing `test.ly'
>> Parsing...
>> test.ly:1: warning: no \version statement found, please add
>>
>> \version "2.19.16"
>>
>> for future compatibility
>> Interpreting music...
>> Preprocessing graphical objects...
>> Finding the ideal number of pages...
>> Fitting music on 1 page...
>> Drawing systems...
>> Layout output to `test.ps'...
>> 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"
> 
> That's a SIGSEGV.  Not something that a GhostScript executable should be
> throwing.  Could it be that the 64-bit cross compilation causes
> problems?

I tried on 32-bit FreeBSD.
The result was just similar.
I tried to execute gs directly.
Then Segmentation fault (core dumped) happened.

linux-x86 binary that I built seems no problem.
I think that it's no problem even if 32-bit binary
is cross compiled by the 64-bit environment.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  writes:

> In mingw, lilypond crashes as follows. 
> Does someone know this reason? 
>
> ```
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
> { c d e f g a b }
>
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
> GNU LilyPond 2.19.16
> Processing `test.ly'
> Parsing...
> test.ly:1: warning: no \version statement found, please add
>
> \version "2.19.16"
>
> for future compatibility
> Interpreting music...
> Preprocessing graphical objects...terminate called after throwing an instance 
> of
>  'std::bad_alloc'
>   what():  std::bad_alloc

No idea.  Looks like out of memory.

> In freebsd-x86, gs fails as follows.
> (I tested this on 64bit FreeBSD. Perhaps it may succeed on 32bit FreeBSD.)
>
> ```
> $ cat test.ly
> { c d e f g a b }
>
> $ ./lilypond test.ly
> GNU LilyPond 2.19.16
> Processing `test.ly'
> Parsing...
> test.ly:1: warning: no \version statement found, please add
>
> \version "2.19.16"
>
> for future compatibility
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `test.ps'...
> 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"

That's a SIGSEGV.  Not something that a GhostScript executable should be
throwing.  Could it be that the 64-bit cross compilation causes
problems?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

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.

  https://github.com/trueroad/gub/tree/binutils-2.24

linux-x86 and linux-64, freebsd-64 lilypond which I built
look like working fine.

In mingw, lilypond crashes as follows. 
Does someone know this reason? 

```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
{ c d e f g a b }

C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
GNU LilyPond 2.19.16
Processing `test.ly'
Parsing...
test.ly:1: warning: no \version statement found, please add

\version "2.19.16"

for future compatibility
Interpreting music...
Preprocessing graphical objects...terminate called after throwing an instance of
 'std::bad_alloc'
  what():  std::bad_alloc

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>
```

In freebsd-x86, gs fails as follows.
(I tested this on 64bit FreeBSD. Perhaps it may succeed on 32bit FreeBSD.)

```
$ cat test.ly
{ c d e f g a b }

$ ./lilypond test.ly
GNU LilyPond 2.19.16
Processing `test.ly'
Parsing...
test.ly:1: warning: no \version statement found, please add

\version "2.19.16"

for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test.ps'...
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"
$ 
```

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> Masamichi HOSODA  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 clear */
>> +memset(buf, 0, sizeof(*buf));
>>  /* Convert to current kernel version of `struct stat'.  */
>>  buf->st_dev = kbuf->st_dev;
> 
> On the surface of it, this looks very reasonable.  However, since
> everything is guarded with #ifdef and similar and the definitions are
> probably generated by autoconf, it would appear that different versions
> of stat.h are employed in the compilation and the resulting mismatch of
> definitions and structures (possibly between host and target
> definitions) could lead to crashes and memory corruption.
> 
> So it would seem like a good idea to first figure out what goes wrong
> here before fixing it in this manner.  It might be a nice fix (and the
> code certainly looks nicer for it) but I have no idea if it is correct.
> The "if it were that easy, it would have been written like that in the
> first place" mantra may be wrong surprisingly often, but it would still
> be nice to make sure.
> 
> -- 
> David Kastrup

librestrict does not have a configure script. 
Therefore, it does not use autoconf.
Furthermore, in my understanding, librestrict is not cross compiled. 
That is, the host and the target is always the same as host OS.

If this is right, I think that my patch does not have a problem. 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA  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 clear */
> + memset(buf, 0, sizeof(*buf));
>   /* Convert to current kernel version of `struct stat'.  */
>   buf->st_dev = kbuf->st_dev;

On the surface of it, this looks very reasonable.  However, since
everything is guarded with #ifdef and similar and the definitions are
probably generated by autoconf, it would appear that different versions
of stat.h are employed in the compilation and the resulting mismatch of
definitions and structures (possibly between host and target
definitions) could lead to crashes and memory corruption.

So it would seem like a good idea to first figure out what goes wrong
here before fixing it in this manner.  It might be a nice fix (and the
code certainly looks nicer for it) but I have no idea if it is correct.
The "if it were that easy, it would have been written like that in the
first place" mantra may be wrong surprisingly often, but it would still
be nice to make sure.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

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));
/* Convert to current kernel version of `struct stat'.  */
buf->st_dev = kbuf->st_dev;
-#ifdef _HAVE_STAT___PAD1
-   buf->__pad1 = 0;
-#endif
buf->st_ino = kbuf->st_ino;
buf->st_mode = kbuf->st_mode;
buf->st_nlink = kbuf->st_nlink;
buf->st_uid = kbuf->st_uid;
buf->st_gid = kbuf->st_gid;
buf->st_rdev = kbuf->st_rdev;
-#ifdef _HAVE_STAT___PAD2
-   buf->__pad2 = 0;
-#endif
buf->st_size = kbuf->st_size;
buf->st_blksize = kbuf->st_blksize;
buf->st_blocks = kbuf->st_blocks;
@@ -77,21 +73,6 @@
buf->st_mtime = kbuf->st_mtime;
buf->st_ctime = kbuf->st_ctime;
 #endif
-#ifdef _HAVE_STAT___UNUSED1
-   buf->__unused1 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED2
-   buf->__unused2 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED3
-   buf->__unused3 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED4
-   buf->__unused4 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED5
-   buf->__unused5 = 0;
-#endif
   }
   break;
 
@@ -116,11 +97,10 @@
   {
struct stat64 *buf = ubuf;
 
+   /* zero clear */
+   memset(buf, 0, sizeof(*buf));
/* Convert to current kernel version of `struct stat64'.  */
buf->st_dev = kbuf->st_dev;
-#ifdef _HAVE_STAT64___PAD1
-   buf->__pad1 = 0;
-#endif
buf->st_ino = kbuf->st_ino;
 #ifdef _HAVE_STAT64___ST_INO
buf->__st_ino = kbuf->st_ino;
@@ -130,9 +110,6 @@
buf->st_uid = kbuf->st_uid;
buf->st_gid = kbuf->st_gid;
buf->st_rdev = kbuf->st_rdev;
-#ifdef _HAVE_STAT64___PAD2
-   buf->__pad2 = 0;
-#endif
buf->st_size = kbuf->st_size;
buf->st_blksize = kbuf->st_blksize;
buf->st_blocks = kbuf->st_blocks;
@@ -148,21 +125,6 @@
buf->st_mtime = kbuf->st_mtime;
buf->st_ctime = kbuf->st_ctime;
 #endif
-#ifdef _HAVE_STAT64___UNUSED1
-   buf->__unused1 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED2
-   buf->__unused2 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED3
-   buf->__unused3 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED4
-   buf->__unused4 = 0;
-#endif
-#ifdef _HAVE_STAT64___UNUSED5
-   buf->__unused5 = 0;
-#endif
   }
   break;
 
@@ -185,12 +147,11 @@
 {
 case _STAT_VER_LINUX:
   {
+   /* zero clear */
+   memset(buf, 0, sizeof(*buf));
/* Convert current kernel version of `struct stat64' to
`struct stat'.  */
buf->st_dev = kbuf->st_dev;
-#ifdef _HAVE_STAT___PAD1
-   buf->__pad1 = 0;
-#endif
 #ifdef _HAVE_STAT64___ST_INO
 # if __ASSUME_ST_INO_64_BIT == 0
if (kbuf->st_ino == 0)
@@ -220,9 +181,6 @@
buf->st_uid = kbuf->st_uid;
buf->st_gid = kbuf->st_gid;
buf->st_rdev = kbuf->st_rdev;
-#ifdef _HAVE_STAT___PAD2
-   buf->__pad2 = 0;
-#endif
buf->st_size = kbuf->st_size;
/* Check for overflow.  */
if (sizeof (buf->st_size) != sizeof (kbuf->st_size)
@@ -253,21 +211,6 @@
buf->st_ctime = kbuf->st_ctime;
 #endif
 
-#ifdef _HAVE_STAT___UNUSED1
-   buf->__unused1 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED2
-   buf->__unused2 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED3
-   buf->__unused3 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED4
-   buf->__unused4 = 0;
-#endif
-#ifdef _HAVE_STAT___UNUSED5
-   buf->__unused5 = 0;
-#endif
   }
   break;
 


> I get:
> 
> ~/gub/target/tools/build/librestrict-1.9.a$ gcc -W -Wall
> -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so
> restrict-stat.c
> In file included from restrict-stat.c:106:0:
> ./xstatconv.c: In function ‘__xstat_conv’:
> ./xstatconv.c:90:5: error: ‘struct stat’ has no member named
> ‘__unused4’
> buf->__unused4 = 0;
> ^
> ./xstatconv.c:93:5: error: ‘struct stat’ has no member named
> ‘__unused5’
> buf->__unused5 = 0;
> ^
> ./xstatconv.c: In function ‘__xstat32_conv’:
> ./xstatconv.c:266:5: error: ‘struct stat’ has no member named
> ‘__unused4’
> buf->__unused4 = 0;
> ^
> ./xstatconv.c:269:5: error: ‘struct stat’ has no member named
> ‘__unused5’
> buf->__unused5 = 0;
> ^
> 
> 
> --
> Phil Holmes
> 
> 
> - Original Message - 
> From: "Jan Nieuwenhuizen" 
> To: "Phil Holmes" 
> Cc: "David Kastrup" ; "Federico Bruni"
> ; 
> Sent: Tuesday, October 28, 2014 12:58 PM
> Su

Re: GUB and mpfr/mpc

[Phil Holmes]

I get:

~/gub/target/tools/build/librestrict-1.9.a$ 
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c

In file included from restrict-stat.c:106:0:
./xstatconv.c: In function ‘__xstat_conv’:
./xstatconv.c:90:5: error: ‘struct stat’ has no member named ‘__unused4’
buf->__unused4 = 0;
^
./xstatconv.c:93:5: error: ‘struct stat’ has no member named ‘__unused5’
buf->__unused5 = 0;
^
./xstatconv.c: In function ‘__xstat32_conv’:
./xstatconv.c:266:5: error: ‘struct stat’ has no member named ‘__unused4’
buf->__unused4 = 0;
^
./xstatconv.c:269:5: error: ‘struct stat’ has no member named ‘__unused5’
buf->__unused5 = 0;
^


--
Phil Holmes


- Original Message - 
From: "Jan Nieuwenhuizen" 

To: "Phil Holmes" 
Cc: "David Kastrup" ; "Federico Bruni" ; 


Sent: Tuesday, 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 -shared -o 
librestrict-stat.so restrict-stat.c


(eg, doing gcc -vvv or cpp -E or somesuch) why it fails to compile.
It's a simple c file with local includes; weird.

Greetings,
Jan


I get:

calculating dependencies
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc librestrict make libtool file tar m4
perl autoconf patch zlib
building package: tools::librestrict
*** Stage: download (librestrict, tools)
*** Stage: untar (librestrict, tools)
*** Stage: patch (librestrict, tools)
*** Stage: shadow (librestrict, tools)
*** Stage: compile (librestrict, tools)
Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
&& gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
-o librestrict-stat.so restrict-stat.c

Tail of target/tools/log/librestrict.log >>>>>>>>
./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
buf->__unused5 = 0;
^
Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
&& gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
-o librestrict-stat.so restrict-stat.c
<<<<<<<< Tail of target/tools/log/librestrict.log

*** Failed target: tools::librestrict


--
Phil Holmes


- Original Message ----- 
From: "Jan Nieuwenhuizen" 

To: "Phil Holmes" 
Cc: "David Kastrup" ; "Federico Bruni"
; 
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 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 autoconf patch zlib
Checking for gcc ... (cached) /usr/bin/gcc
building package: system::gcc
*** Stage: download (gcc, system)
*** Stage: configure (gcc, system)
Checking for gcc ... (cached) /usr/bin/gcc

building package: tools::librestrict
*** Stage: download (librestrict, tools)
*** Stage: untar (librestrict, tools)
*** Stage: patch (librestrict, tools)
*** Stage: shadow (librestrict, tools)
*** Stage: compile (librestrict, tools)
*** Stage: install (librestrict, tools)
*** Stage: package (librestrict, tools)
*** Stage: clean (librestrict, tools)
*** Stage: pkg_install (librestrict, tools)

[...]


--
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Jan Nieuwenhuizen]

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  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Jan Nieuwenhuizen]

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 librestrict-stat.so 
restrict-stat.c 

 (eg, doing gcc -vvv or cpp -E or somesuch) why it fails to compile.
It's a simple c file with local includes; weird.

Greetings,
Jan

> I get:
>
> calculating dependencies
> Checking for gcc ... /usr/bin/gcc
> must rebuild[tools]: system::gcc librestrict make libtool file tar m4
> perl autoconf patch zlib
> building package: tools::librestrict
> *** Stage: download (librestrict, tools)
> *** Stage: untar (librestrict, tools)
> *** Stage: patch (librestrict, tools)
> *** Stage: shadow (librestrict, tools)
> *** Stage: compile (librestrict, tools)
> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
> && gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
> librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
> -o librestrict-stat.so restrict-stat.c
>
> Tail of target/tools/log/librestrict.log >>>>>>>>
> ./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
> buf->__unused5 = 0;
> ^
> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
> && gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
> librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
> -o librestrict-stat.so restrict-stat.c
> <<<<<<<< Tail of target/tools/log/librestrict.log
>
> *** Failed target: tools::librestrict
>
>
> --
> Phil Holmes
>
>
> - Original Message - 
> From: "Jan Nieuwenhuizen" 
> To: "Phil Holmes" 
> Cc: "David Kastrup" ; "Federico Bruni"
> ; 
> 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 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 autoconf patch zlib
> Checking for gcc ... (cached) /usr/bin/gcc
> building package: system::gcc
> *** Stage: download (gcc, system)
> *** Stage: configure (gcc, system)
> Checking for gcc ... (cached) /usr/bin/gcc
>
> building package: tools::librestrict
> *** Stage: download (librestrict, tools)
> *** Stage: untar (librestrict, tools)
> *** Stage: patch (librestrict, tools)
> *** Stage: shadow (librestrict, tools)
> *** Stage: compile (librestrict, tools)
> *** Stage: install (librestrict, tools)
> *** Stage: package (librestrict, tools)
> *** Stage: clean (librestrict, tools)
> *** Stage: pkg_install (librestrict, tools)
>
> [...]

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Dan Eble]

On Oct 28, 2014, at 07:25 , Phil Holmes  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 __unused?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

I get:

calculating dependencies
Checking for gcc ... /usr/bin/gcc
must rebuild[tools]: system::gcc librestrict make libtool file tar m4 perl 
autoconf patch zlib

building package: tools::librestrict
*** Stage: download (librestrict, tools)
*** Stage: untar (librestrict, tools)
*** Stage: patch (librestrict, tools)
*** Stage: shadow (librestrict, tools)
*** Stage: compile (librestrict, tools)
Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a && 
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c


Tail of target/tools/log/librestrict.log >>>>>>>>
./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
buf->__unused5 = 0;
^
Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a && 
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c

<<<<<<<< Tail of target/tools/log/librestrict.log

*** Failed target: tools::librestrict


--
Phil Holmes


- Original Message - 
From: "Jan Nieuwenhuizen" 

To: "Phil Holmes" 
Cc: "David Kastrup" ; "Federico Bruni" ; 


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 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 
autoconf patch zlib

Checking for gcc ... (cached) /usr/bin/gcc
building package: system::gcc
*** Stage: download (gcc, system)
*** Stage: configure (gcc, system)
Checking for gcc ... (cached) /usr/bin/gcc

building package: tools::librestrict
*** Stage: download (librestrict, tools)
*** Stage: untar (librestrict, tools)
*** Stage: patch (librestrict, tools)
*** Stage: shadow (librestrict, tools)
*** Stage: compile (librestrict, tools)
*** Stage: install (librestrict, tools)
*** Stage: package (librestrict, tools)
*** Stage: clean (librestrict, tools)
*** Stage: pkg_install (librestrict, tools)

[...]

--
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Jan Nieuwenhuizen" 
Cc: "Phil Holmes" ; "Federico Bruni" 
; 

Sent: Tuesday, October 28, 2014 10:58 AM
Subject: Re: GUB and mpfr/mpc



Jan Nieuwenhuizen  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



Mine is 32 bit in a VM.

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Jan Nieuwenhuizen  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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Jan Nieuwenhuizen]

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 
autoconf patch zlib
Checking for gcc ... (cached) /usr/bin/gcc
building package: system::gcc
 *** Stage: download (gcc, system)
 *** Stage: configure (gcc, system)
Checking for gcc ... (cached) /usr/bin/gcc

building package: tools::librestrict
 *** Stage: download (librestrict, tools)
 *** Stage: untar (librestrict, tools)
 *** Stage: patch (librestrict, tools)
 *** Stage: shadow (librestrict, tools)
 *** Stage: compile (librestrict, tools)
 *** Stage: install (librestrict, tools)
 *** Stage: package (librestrict, tools)
 *** Stage: clean (librestrict, tools)
 *** Stage: pkg_install (librestrict, tools)

[...]

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

- Original Message - 
From: "Jan Nieuwenhuizen" 



What repository are you using?



Greetings, Jan


https://github.com/gperciva/gub

--
Phil Holmes

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Jan Nieuwenhuizen]

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, tools)
>> *** Stage: shadow (librestrict, tools)
>> *** Stage: compile (librestrict, tools)
>> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
>> && gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
>> librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
>> -o librestrict-stat.so restrict-stat.c
>>
>> Tail of target/tools/log/librestrict.log 
>> ./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
>> buf->__unused5 = 0;
>> ^
>> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
>> && gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
>> librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
>> -o librestrict-stat.so restrict-stat.c

>>  Tail of target/tools/log/librestrict.log

Have you looked at the logfile?

> So it would appear that librestrict has been written by Jan.  The error
> you see does not appear like a failure of librestrict (like described)
> but rather a failure to build librestrict in the first place.

> Jan?

You give me too much credit, as git may tell you.  I did add
xstatconv.c.  Indeed, building librestrict fails; but it works
for me.

What repository are you using?

Greetings, Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "Phil Holmes" 
> To: "Federico Bruni" 
> Cc: 
> 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 to use a current version of gcc, I
>> need at least 12.04 and I might as well go to 14.04 in order to
>> build GUB?
>>
>> --
>> Phil Holmes
>
> 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, tools)
> *** Stage: shadow (librestrict, tools)
> *** Stage: compile (librestrict, tools)
> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
> && gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
> librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
> -o librestrict-stat.so restrict-stat.c
>
> Tail of target/tools/log/librestrict.log >>>>>>>>
> ./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
> buf->__unused5 = 0;
> ^
> Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a
> && gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o
> librestrict-stat.so restrict-stat.c || gcc -W -Wall -I. -fPIC -shared
> -o librestrict-stat.so restrict-stat.c
> <<<<<<<< Tail of target/tools/log/librestrict.log
>
> *** Failed target: tools::librestrict
> make: *** [bootstrap-git] Error 1
>
> Anyone know why?

struct stat is defined in  (for example).  It does not
contain anything like __unused5 as far as I can see.  My guess would be
that this is defined in an alternative version in some header file of
restrict-stat.c and that this definition and the system definition get
mixed up, possibly by something else including the system definition via
some other means.

But I have, frankly, no idea what librestrict might be and what it is
used for.  So this is totally handwavy.

Actually, I read on http://lilypond.org/gub/basics>

LIBRESTRICT

A common problem with [making reproducible cross] builds is using
files or features that are not controlled by the [GUB] build
process, but just happen to be on the build host and happen to
differ between most build hosts.

GUB uses the LD_PRELOAD feature with the gub/specs/librestrict.py
package and code from ./librestrict/restrict.c to disallow reading
from build host files. This makes for much better reprocucibility,
especially between different build hosts.

The downside to this LIBRESTRICT feature is that quite a few
packages are not prepared for cross building. LIBRESTRICT will catch
these errors and they have to be fixed in the package's spec file.

This is what such a LIBRESTRICT assertion could like


librestrict:error:/home/janneke/vc/gub/target/mingw/root/usr/cross/libexec/gcc/i686-mingw32/4.1.1/cc1plus:
 tried to open () file /home/janneke/vc/lilypond/lily/main.cc
librestrict:allowed:
  /home/janneke/vc/gub/target/mingw
  /tmp
  /dev/null
  /dev/urandom
  /proc/self
cc1plus: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[1]10:42:08 janneke@peder:~/vc/gub
$ 

you often find these in config.log files when package-dependant code
blondly looks in /usr/include or /usr/lib.

So it would appear that librestrict has been written by Jan.  The error
you see does not appear like a failure of librestrict (like described)
but rather a failure to build librestrict in the first place.

Jan?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: "Federico Bruni" 
Cc: 
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 to use a current version of gcc, I need 
at least 12.04 and I might as well go to 14.04 in order to build GUB?


--
Phil Holmes


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, tools)
*** Stage: shadow (librestrict, tools)
*** Stage: compile (librestrict, tools)
Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a && 
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c


Tail of target/tools/log/librestrict.log >>>>>>>>
./xstatconv.c:269:5: error: 'struct stat' has no member named '__unused5'
buf->__unused5 = 0;
^
Command barfed: cd /home/gub/gub/target/tools/build/librestrict-1.9.a && 
gcc -W -Wall -fno-stack-protector -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c || gcc -W -Wall -I. -fPIC -shared -o librestrict-stat.so 
restrict-stat.c

<<<<<<<< Tail of target/tools/log/librestrict.log

*** Failed target: tools::librestrict
make: *** [bootstrap-git] Error 1

Anyone know why?

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

It's my computer (or strictly, a VM on my computer).

So it would appear that in order to use a current version of gcc, I need at 
least 12.04 and I might as well go to 14.04 in order to build GUB?

--
Phil Holmes


  - Original Message - 
  From: Federico Bruni 
  To: Phil Holmes 
  Cc: 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  ha 
scritto:

- Original Message - From: "Masamichi HOSODA" 
 
  libgmp-dev package exists after Ubuntu 12.04. 
http://packages.ubuntu.com/search?keywords=libgmp-dev&searchon=names&suite=all§ion=all
 My environment is Ubuntu 14.04LTS amd64. Are you using Ubuntu 10.04? 
Afraid so. 


  $ lsb_release -a


  will tell you exactly.
  Is it the server or your computer?


  You need at least 12.04:
  http://packages.ubuntu.com/search?keywords=libgmp-dev

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "Masamichi HOSODA" 
>
>> libgmp-dev package exists after Ubuntu 12.04.
>> http://packages.ubuntu.com/search?keywords=libgmp-dev&searchon=names&suite=all§ion=all
>>
>> My environment is Ubuntu 14.04LTS amd64.
>> Are you using Ubuntu 10.04?
>
>
> Afraid so.

So there is the next thing wanting an update: that's two stable releases
back IIRC.  14.04 is pretty ok, I think.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Federico Bruni]

Il giorno sab 25 ott 2014 alle 17:18, Phil Holmes  
ha scritto:
- Original Message - From: "Masamichi HOSODA" 




libgmp-dev package exists after Ubuntu 12.04.
http://packages.ubuntu.com/search?keywords=libgmp-dev&searchon=names&suite=all§ion=all

My environment is Ubuntu 14.04LTS amd64.
Are you using Ubuntu 10.04?



Afraid so.


$ lsb_release -a

will tell you exactly.
Is it the server or your computer?

You need at least 12.04:
http://packages.ubuntu.com/search?keywords=libgmp-dev


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

- Original Message - 
From: "Masamichi HOSODA" 



libgmp-dev package exists after Ubuntu 12.04.
http://packages.ubuntu.com/search?keywords=libgmp-dev&searchon=names&suite=all§ion=all

My environment is Ubuntu 14.04LTS amd64.
Are you using Ubuntu 10.04?



Afraid so.

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> - Original Message - 
> From: "Masamichi HOSODA" 
> To: 
> Cc: ; 
> Sent: Saturday, October 25, 2014 2:58 PM
> Subject: Re: GUB and mpfr/mpc
> 
> 
>>> - Original Message - 
>>> From: "Masamichi HOSODA" 
>>> To: 
>>> 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 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 no mention of MPC as a package in the current version of GUB.
>>>>> My
>>>>> most recent failure says this:
>>>>>
>>>>> checking for the correct version of gmp.h... buggy but acceptable
>>>>> checking for the correct version of mpfr.h... yes
>>>>> checking for the correct version of mpc.h... no
>>>>> configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC
>>>>> 0.8.0+.
>>>>>
>>>>> So it looks like we need to add a dependency on MPC.  Problem is, I
>>>>> don't
>>>>> have a clue how to do this.  I could try some stuff, but can anyone
>>>>> here
>>>>> help with how this dependency should be added to GUB?
>>>>>
>>>>> TIA.
>>>>
>>>> Did the error occur, while building cross/gcc?
>>>> If that is right, GMP/MPFR/MPC may be required for not GUB but host
>>>> OS.
>>>
>>>
>>> The error is in the linux-86/log/cross/gcc-core.log file, so I assume
>>> the answer is yes.  However, my understanding is that the only package
>>> that should need separately installing on plain Ubuntu/linux is git:
>>> the rest should be downloaded and built by make bootstrap.
>>>
>>> --
>>> Phil Holmes
>>>
>>
>> cross/gcc-core is built by host OS native gcc.
>> Would you try the following commands on your Ubuntu?
>>
>> sudo apt-get update
>> sudo apt-get install libgmp-dev
>> sudo apt-get install libmpfr-dev
>> sudo apt-get install libmpc-dev
>>
>> In my environment, I have succeeded in building of
>> linux-x86::cross/gcc-core.
>> However, I have still failed in building of linux-x86::glibc-core.
>>
>> https://github.com/trueroad/gub/tree/binutils-2.24
>>
> 
> apt-get update ran fine.  However, I get this for libgmp:
> 
> gub@gub-V2:~/gub$ sudo apt-get install libgmp-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Couldn't find package libgmp-dev
> 
> --
> Phil Holmes 
> 

libgmp-dev package exists after Ubuntu 12.04.
http://packages.ubuntu.com/search?keywords=libgmp-dev&searchon=names&suite=all§ion=all

My environment is Ubuntu 14.04LTS amd64.
Are you using Ubuntu 10.04?

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

- Original Message - 
From: "Masamichi HOSODA" 

To: 
Cc: ; 
Sent: Saturday, October 25, 2014 2:58 PM
Subject: Re: GUB and mpfr/mpc


- Original Message - 
From: "Masamichi HOSODA" 

To: 
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 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 no mention of MPC as a package in the current version of GUB.
My
most recent failure says this:

checking for the correct version of gmp.h... buggy but acceptable
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC
0.8.0+.

So it looks like we need to add a dependency on MPC.  Problem is, I
don't
have a clue how to do this.  I could try some stuff, but can anyone
here
help with how this dependency should be added to GUB?

TIA.


Did the error occur, while building cross/gcc?
If that is right, GMP/MPFR/MPC may be required for not GUB but host
OS.



The error is in the linux-86/log/cross/gcc-core.log file, so I assume
the answer is yes.  However, my understanding is that the only package
that should need separately installing on plain Ubuntu/linux is git:
the rest should be downloaded and built by make bootstrap.

--
Phil Holmes



cross/gcc-core is built by host OS native gcc.
Would you try the following commands on your Ubuntu?

sudo apt-get update
sudo apt-get install libgmp-dev
sudo apt-get install libmpfr-dev
sudo apt-get install libmpc-dev

In my environment, I have succeeded in building of 
linux-x86::cross/gcc-core.

However, I have still failed in building of linux-x86::glibc-core.

https://github.com/trueroad/gub/tree/binutils-2.24



apt-get update ran fine.  However, I get this for libgmp:

gub@gub-V2:~/gub$ sudo apt-get install libgmp-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package libgmp-dev

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> - Original Message - 
> From: "Masamichi HOSODA" 
> To: 
> 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 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 no mention of MPC as a package in the current version of GUB.
>>> My
>>> most recent failure says this:
>>>
>>> checking for the correct version of gmp.h... buggy but acceptable
>>> checking for the correct version of mpfr.h... yes
>>> checking for the correct version of mpc.h... no
>>> configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC
>>> 0.8.0+.
>>>
>>> So it looks like we need to add a dependency on MPC.  Problem is, I
>>> don't
>>> have a clue how to do this.  I could try some stuff, but can anyone
>>> here
>>> help with how this dependency should be added to GUB?
>>>
>>> TIA.
>>
>> Did the error occur, while building cross/gcc?
>> If that is right, GMP/MPFR/MPC may be required for not GUB but host
>> OS.
> 
> 
> The error is in the linux-86/log/cross/gcc-core.log file, so I assume
> the answer is yes.  However, my understanding is that the only package
> that should need separately installing on plain Ubuntu/linux is git:
> the rest should be downloaded and built by make bootstrap.
> 
> --
> Phil Holmes 
> 

cross/gcc-core is built by host OS native gcc.
Would you try the following commands on your Ubuntu?

sudo apt-get update
sudo apt-get install libgmp-dev
sudo apt-get install libmpfr-dev
sudo apt-get install libmpc-dev

In my environment, I have succeeded in building of linux-x86::cross/gcc-core.
However, I have still failed in building of linux-x86::glibc-core. 

https://github.com/trueroad/gub/tree/binutils-2.24

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Phil Holmes]

- Original Message - 
From: "Masamichi HOSODA" 

To: 
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 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 no mention of MPC as a package in the current version of GUB.  My
most recent failure says this:

checking for the correct version of gmp.h... buggy but acceptable
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC
0.8.0+.

So it looks like we need to add a dependency on MPC.  Problem is, I don't
have a clue how to do this.  I could try some stuff, but can anyone here
help with how this dependency should be added to GUB?

TIA.


Did the error occur, while building cross/gcc?
If that is right, GMP/MPFR/MPC may be required for not GUB but host OS.



The error is in the linux-86/log/cross/gcc-core.log file, so I assume the 
answer is yes.  However, my understanding is that the only package that 
should need separately installing on plain Ubuntu/linux is git: the rest 
should be downloaded and built by make bootstrap.


--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[Masamichi HOSODA]

> 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 no mention of MPC as a package in the current version of GUB.  My 
> most recent failure says this:
> 
> checking for the correct version of gmp.h... buggy but acceptable
> checking for the correct version of mpfr.h... yes
> checking for the correct version of mpc.h... no
> configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 
> 0.8.0+.
> 
> So it looks like we need to add a dependency on MPC.  Problem is, I don't 
> have a clue how to do this.  I could try some stuff, but can anyone here 
> help with how this dependency should be added to GUB?
> 
> TIA.
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

Did the error occur, while building cross/gcc?
If that is right, GMP/MPFR/MPC may be required for not GUB but host OS.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB and mpfr/mpc

[David Kastrup]

Phil Holmes  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 that older versions did not: there 
> appears no mention of MPC as a package in the current version of GUB.  My 
> most recent failure says this:
>
> checking for the correct version of gmp.h... buggy but acceptable
> checking for the correct version of mpfr.h... yes
> checking for the correct version of mpc.h... no
> configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 
> 0.8.0+.
>
> So it looks like we need to add a dependency on MPC.  Problem is, I don't 
> have a clue how to do this.  I could try some stuff, but can anyone here 
> help with how this dependency should be added to GUB?

Jan?

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel