Hi Ken,
On Mon, 2021-09-06 at 17:24 -0400, Ken Brown via Cygwin wrote:
> You're looking at the wrong source code. The bug didn't occur until
> the code
> was changed to do the following:
You are right. I do not know why i looked at an old checkout of the
code. Shame on me! Sorry for wasting you
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait. I get what you say. The optimzation settings of the test
> > case should have no influence on the code inside the DLL. That
> > doesn't
> > make sense for sure. However, I ran the testcase under GDB, I could
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait. I get what you say. The optimzation settings of the test
> > case should have no influence on the code inside the DLL. That
> > doesn't
> > make sense for sure. However, I ran the testcase under GDB, I could
Hi Corinna,
On Thu, 2020-08-20 at 14:50 +0200, Corinna Vinschen wrote:
> No, it won't work as expected, as you can see from the discussion in
>
> this thread. Some internal work would be required.
OK. So even with no file actions and spawn atributes, it still would
break things.
What kind of t
Hi Corinna,
> spawn alone doesn't cut it, due to the requirement to support the
> additional file actions and spawn atributes POSIX defines. This
> would require a revamp of Cygwin's spawn functionality, which is
> already quite complicated. So this is something I'm only willing
> to do in homeo
Hi all,
On Fri, 2020-07-31 at 10:10 +0200, Corinna Vinschen wrote:
> Oh well. I did a quick test with your new testcase (thanks for
> that!)
> and it seems to be a bit more complicated than I anticipated
> yesterday.
> The parent-child relationship between the processes is broken. I
> have
> to
On Thu, 2020-04-16 at 08:35 -0600, Brian Inglis wrote:
> On 2020-04-15 04:44, Mail Delivery System via Cygwin wrote:
> > This is the mail system at host sourceware.org.
> > I'm sorry to have to inform you that your message could not
> > be delivered to one or more recipients. It's attached below.
>
Hi Mike,
> Is it possible use Cygwin to run an autotools 'configure' script but
> have the compiler be MSVC?
Yeah, sure, i have done this in the past.
"./configure CC=cl.exe" should get you going as far as i remember. Make
sure your MS tools are in your PATH.
There are limitations though, as so
Hi Takashi,
On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote:
> Could you please try latest snapshot?
> https://cygwin.com/snapshots/
The commit regarding use of kill() does the trick.
It's a go from here :-).
Thanks for all the help,
/pedro
--
Problem reports: http://cygwin.com/pr
Hi Takashi,
Thanks for your effort.
On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote:
> however, I found the real cause is that errno is accidentally set
> by kill() in pty system calls. That is, the problem is not in the
> kill() itself but in usage of it. Cygwin older than 3.1.0 does not
>
On Tue, 2020-02-11 at 11:38 +0100, Peter Dons Tychsen wrote:
> processes. And why did this work before?
And why does it work when running without minnty? How does that play
into this?
Thanks,
/pedro
--
Problem reports: http://cygwin.com/problems.html
FAQ: h
Hi Takashi,
Thanks for looking at this & your great work on Cygwin!
On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote:
> Is this the same as your problem?
Yeah, it could be. Could this result in fork error messages as we are
seeing all over the place?
> If so, it goes without stopping 1 min
Hi all,
On Thu, 2020-02-06 at 09:18 +1100, David Finnie wrote:
> That would be awesome if you could create a small test case
OK, i put together a test-case:
1) Put attached makefile somewhere
2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe
and unzip it in same place.
3) Now
Hi David & Co,
> I have started down the road of building cygwin, but did run into a
> few issues so don't have a debuggable version yet. If you beat me to
> it, please let me know. Thanks!
Any findings?
I have found something interesting:
1) If i run the terminal without mintty, the problem g
Hi Cygwinners,
On Thu, 2020-01-02 at 10:43 +1100, David Finnie wrote:
> I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !)
>
> That has fixed the issue for me, and the make it now running again
> at
> full speed. I forgot to mention that it did seem somewhat slower
> with
> the new
On Wed, 2019-10-23 at 10:18 +0200, Peter Dons Tychsen wrote:
> OK thanks,
>
> I will keep an eye out for them :-)
>
> Thanks,
>
> /pedro
And sorry for the top post. I have just now slapped myself as
punishment :-).
/pedro
--
Problem reports: http://cygwin.
OK thanks,
I will keep an eye out for them :-)
Thanks,
/pedro
On Tue, 2019-10-22 at 19:40 +0200, Corinna Vinschen wrote:
> On Oct 22 19:11, donpedro.tdcadsl.dk via cygwin wrote:
> > Hello all.
> >
> > There does not appear to be any snaps any more at:
> > https://cygwin.com/snapshots/
> >
>
Hi Ken,
> I think you're probably right. The use of FE_NNF in execvp* was
> introduced in
> commit 6d63272b. I suspect it was just an oversight that the spawvp*
> functions
> weren't changed in the same way. I'll send a patch to the cygwin-
> patches list
> to fix this. When Corinna returns
Hello Yaakov & co.
Are there plans to update these any time soon? I could fear that other
mingw packages (at least the c++ ones) suffer the same problem
currently.
On another note, thanks Yaakov for maintaining so many mingw packes all
together. I really appreciate it. I makes windows development
Hello.
The WEXITSTATUS is a bit buggy. (wait.h)
The macro extracts information gained from a call to waitpid() (and others).
The information it extracts is the status of the completed process (8 bit
signed value).
The problem is that the macro does not cast the value to a signed integer
(like ot
20 matches
Mail list logo
