I'm having the problem that under cygwin flushing stdin for some reason doesn't
work when running in mintty. It works when running cygwin in the Windows
terminal though. In my case the program using this is pacman, where it asks
various questions and if you hit some keys in-between questions they l
Starting with 3.6.0 when cmake calls into make/ninja/gcc there is a chance of
that failing, for example like this:
CMake Error: Generator: build tool execution failed, command was:
/usr/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.exe -f Makefile
cmTC_c87e2/fast
* Problem starts with cygwin 3.6.0
After the upgrade to 3.4 (disclaimer: in MSYS2) I'm seeing, and getting reports
of, various things failing in Docker only, for example:
1 [main] pacman 252 child_copy: dll data read copy failed,
0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 5096, Win32 error
299
0 [main] pacman 2
I can confirm that reverting the asm change in
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=188d5f6c9ad5cbbd6f0fcb9aaf15bc9870597910
seems to make things work again.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
The following example works with 3.3.6, but fails with 3.4.2. It's a
reduced example from pacman which started to produce garbage output in
some places after upgrading to 3.4.2. While I noticed it in MSYS2
first, I have confirmed it with 3.3.6 and 3.4.2 in cygwin.
```
#include
#include
#include
On Fri, Mar 19, 2021 at 11:09 AM Takashi Yano via Cygwin
wrote:
>
> On Thu, 18 Mar 2021 21:28:40 +0100
> Christoph Reiter wrote:
> > I noticed that the stdin pipe was renamed from
> >
> > "\msys-dd50a72ab4668b33-pty1-from-master" to
> > "\msys-dd50a72ab4668b33-pty0-to-slave" in
> > https://cygwin.
On Fri, Mar 19, 2021 at 4:47 AM Brian Inglis
wrote:
>
> On 2021-03-18 14:28, Christoph Reiter via Cygwin wrote:
> If these are being renamed should they not now use neutral terminology based
> on
> terms such as primary and secondary, and the primary/default repo branches on
>
Hey,
I noticed that the stdin pipe was renamed from
"\msys-dd50a72ab4668b33-pty1-from-master" to
"\msys-dd50a72ab4668b33-pty0-to-slave" in
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=bb42852062073439
This trips up https://github.com/k-takata/ptycheck to detect the
cygpty which is used
On Fri, Mar 5, 2021 at 5:50 PM L A Walsh wrote:
> Really I don't see a compelling reason there should be
> any hurry to update. In my own testing, I've been unable to
> build a version that doesn't crash/dump core on linux and don't
> really think the 5.x series has had a thorough vetting
On Sun, Feb 28, 2021 at 3:22 PM ASSI wrote:
>
> Christoph Reiter via Cygwin writes:
> > MSYS2 builds all packages with ASLR since 6 months, so things look
> > good.
>
> That doesn't tell you all that much since you will have to wait for some
> unfavorable addre
On Sun, Feb 28, 2021 at 1:16 PM ASSI wrote:
>
> Christoph Reiter via Cygwin writes:
> > binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled
> > linker
> > will give you:
> >
> >> peflags -v mydll.dll
> > mydll.dll: coff(0x2026[+
Hey,
binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled linker
will give you:
> peflags -v mydll.dll
mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll])
pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat])
Is this still problematic for cygwin?
The re
12 matches
Mail list logo
