[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.
>
> <
> 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