On Wed, 25 Dec 2024 15:33:13 -0800 (PST) Jeremy Drake wrote: > On Wed, 25 Dec 2024, Takashi Yano via Cygwin wrote: > > > On Tue, 24 Dec 2024 22:34:44 +0100 > > Bruno Haible wrote: > > > This is not reproducible, but here's the report anyway: > > > > > > I upgraded a Windows 10 system from Cygwin 3.5.3 to 3.5.5 today. > > > Then ran the configure script of a tarball (*), and it hung: > > > > > > $ mkdir build-cygwin64 > > > $ cd build-cygwin64 > > > $ ../configure --host=x86_64-pc-cygwin --prefix=/usr/local/cygwin64 > > > CC=x86_64-pc-cygwin-gcc CXX=x86_64-pc-cygwin-g++ > > > CPPFLAGS="-I/usr/local/cygwin64/include -Wall" > > > LDFLAGS=-L/usr/local/cygwin64/lib -C --with-included-libunistring 2>&1 | > > > tee log1 > > > ... > > > checking whether snprintf fully supports the 'n' directive... (cached) yes > > > checking whether snprintf respects a size of 1... (cached) yes > > > checking whether vsnprintf respects a zero size as in C99... (cached) yes > > > checking whether btowc is declared without a macro... yes > > > checking whether wctob is declared without a macro... yes > > > checking whether mbsinit is declared without a macro... yes > > > checking whether mbrtowc is declared without a macro... yes > > > <hangs> > > > > > > Typing Ctrl-C in said mintty window has no effect. > > > > > > > > > (*) generated in a gnulib checkout on Linux, through > > > $ ./gnulib-tool --create-testdir --dir=../testdir-all > > > --with-c++-tests --without-privileged-tests --single-configure > > > `./all-modules` > > > > This may be the same issue with: > > https://cygwin.com/pipermail/cygwin/2024-December/256954.html > > We ran into hang issues with libtool linking imagemagick in msys2, using > version based on 3.5.5, 3 times in a row on our ARM64 runner. We applied > your v2 patch to our 3.5.5 branch (with the change of current_sig to sig), > and the issue no longer occurred. (I also tested with the existing 3.5.4 > version, and it didn't hang either).
Thanks for testing v2 patch. > Note that kill -CHLD to either the child sh.exe or the parent make.exe did > not unblock things, but killing sh.exe (SIGTERM) did cause the make to > fail as expected. Perhaps, the signal that sh is waiting for is different than that of zsh case. -- Takashi Yano <takashi.y...@nifty.ne.jp> -- 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
