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 <cori...@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 <cori...@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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
