[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a new way to build LilyPond binary releases

From: Jonas Hahnfeld
Subject: Re: a new way to build LilyPond binary releases
Date: Wed, 11 Mar 2020 19:17:50 +0100
User-agent: Evolution 3.34.4

Am Mittwoch, den 11.03.2020, 11:38 -0500 schrieb Karlin High:
> On Wed, Mar 11, 2020 at 10:56 AM Jonas Hahnfeld <
> address@hidden
> > wrote:
> > Please let me know if something doesn't work at all
> That sounds like an interesting project. I tested the Windows version,
> and it works. I got a PDF from compiling { c' } as a hello-world test.
> Now, is this supposed to be a 64-bit application? I can easily get
> confused about 64-bit MinGW vs 64-bit applications on it. LilyPond's
> 32-bit Windows version is susceptible to out-of-memory crashes.

Yes, this is supposed to be a 64bit executable and I had really hoped
that it puts an end to the out-of-memory crashes.

> <
> >
> I tried the test in that thread, on both the official LilyPond 2.19.84
> and the binary you shared. Both crash, but with slightly different
> error messages:
> Offical 2.19.84 says...
> Preprocessing graphical objects...terminate called after throwing an
> instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> This binary from GitHub says...
> Preprocessing graphical objects...Exception code=0xc0000005 flags=0x0
> at 0x00000000005056A5. Access violation - attempting to read data at
> address 0x0000000000000000

Hmm, that's not really better, is it? The good thing is that I can
reproduce a crash with the binary for GNU/Linux, so it's got to do with
the way the scripts build statically. I'll take a look.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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