Re: a new way to build LilyPond binary releases

[Jonas Hahnfeld]

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.

> 
> <
> https://lists.gnu.org/archive/html/lilypond-user/2018-12/msg00408.html
> >
> 
> 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.

Jonas

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