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
10 matches
Mail list logo
