segfault on 32bit cygwin snapshot

[marco atzeri]

On Mon, Mar 1, 2021 at 12:59 PM Takashi Yano via Cygwin  wrote:
>
> On Mon, 1 Mar 2021 17:41:57 +0900
> Takashi Yano wrote:
> > On Mon, 1 Mar 2021 09:55:46 +0900
> > Takashi Yano wrote:
> > > On Sun, 28 Feb 2021 19:48:28 +0100
> > > Marco Atzeri wrote:
> > > > On 20.02.2021 23:29, Takashi Yano wrote:
> > > > > On Sat, 20 Feb 2021 22:01:38 +0100
> > > > > Marco Atzeri wrote:

> > > > but I found another issue
> > > >
> > > >   $ /usr/bin/lilypond
> > > > GNU LilyPond 2.20.0
> > > > Segmentation fault (core dumped)
> > > >
> > > > on 3.1.7 it works fine
> > >
> > > I found this problem causes after the commit:
> > >
> > > commit 532b91d24e9496c7988b2b1dda7fc0e8b161f782
> > > Author: Corinna Vinschen <corinna@vinschen.de>
> > > Date:   Mon Dec 14 12:29:23 2020 +0100
> > >
> > >     Cygwin: Make sure newer apps get uname_x even when loading uname dynamically
> > >
> > >     if an application built after API version 334 loads uname dynamically,
> > >     it actually gets the old uname, rather than the new uname_x.  Fix this by
> > >     checking the apps API version in uname and call uname_x instead, if it's
> > >     a newer app.
> > >
> > >     Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
> > >
> > > Reverting this commit solves the issue.
> > >
> > > Corinna, could you please have a look?
> >
> > I looked into this deeper a bit.
> >
> > Perhaps, lilypond passes old small sized utsname structure to
> > uname() via old cygguile-17.dll (built on Apr. 2017). This seems
> > to cause stack destruction.
>
> So, I guess rebuilding and replacing cygguile-17.dll will solve
> the issue. However, I am not sure whehter the new binary works
> with cygwin 3.1.7.
>
> --
> Takashi Yano

I can rebuild cygguile-17.dll and see if work also with 3.1.7
but I wonder which other DLL's will suffer the same problem