On Feb 26 20:08, Dimitry Andric via Cygwin wrote:
> On 26 Feb 2024, at 20:03, Corinna Vinschen wrote:
> >
> > On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> >> Hi,
> >>
> >> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> >> (see https://cygwin.com/pipermail/cygwin/
On 26 Feb 2024, at 20:03, Corinna Vinschen wrote:
>
> On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
>> Hi,
>>
>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
>> 3.5.0-1, I now get spurious "er
On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> Hi,
>
> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
> GNU make 4.4.1-2,
On 26 Feb 2024, at 18:30, Marco Atzeri via Cygwin wrote:
>
> On 26/02/2024 18:16, Dimitry Andric via Cygwin wrote:
>> On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote:
>>>
>>> On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
Hi,
After a recent upgrade of a Cygwin installat
On 26/02/2024 18:16, Dimitry Andric via Cygwin wrote:
On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote:
On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024-Februar
On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote:
>
> On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
>> Hi,
>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
>> 3.5.0-1, I now get spuri
On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
GNU make 4.4.1-2, when
> Sorry, the second gdb command should be
> info line *__assert+0x42a4
> > (Note the change in symbol name: two "_" there)
>
I think it'd be easier to "catch" the problem rather than to chase it by
running all commands under the debugger.
For that, define the CYGWIN environment variable (vi
Sorry, the second gdb command should be
info line *__assert+0x42a4
(Note the change in symbol name: two "_" there)
..mark
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe i
Hi Derek,
Derek Pagel via Cygwin wrote:
We've had problems with slow Cygwin commands, so we were able to capture a
stack trace when the 'cp' program taking a long time to complete, and we
noticed in the stack trace that the last thing cygwin1.dll does is calls
assert. What might that suggest?
On Dec 3 10:58, Mattl Mario wrote:
> Hello everyone,
>
> I can confirm:
> with the latest snapshot-DLL, it is working fine again. (as Corinna mentioned)
Thanks for testing!
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documenta
On Dec 3 18:30, Takashi Yano via Cygwin wrote:
> On Wed, 2 Dec 2020 16:35:02 +0100
> Corinna Vinschen via Cygwin wrote:
> > On Dec 2 15:05, Corinna Vinschen wrote:
> > > On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> > > > On Tue, 1 Dec 2020 19:13:39 -0500
> > > > Ken Brown via Cygwin wrote:
On Wed, 2 Dec 2020 16:35:02 +0100
Corinna Vinschen via Cygwin wrote:
> On Dec 2 15:05, Corinna Vinschen wrote:
> > On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> > > On Tue, 1 Dec 2020 19:13:39 -0500
> > > Ken Brown via Cygwin wrote:
> > > > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > > >
On Dec 2 15:05, Corinna Vinschen wrote:
> On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> > On Tue, 1 Dec 2020 19:13:39 -0500
> > Ken Brown via Cygwin wrote:
> > > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > > Hello,
> > > >
> > > > Since cygwin1.dll version 3.1.5, I observed the following
On Dec 2 15:07, Thomas Wolff wrote:
>
>
> Am 02.12.2020 um 15:05 schrieb Corinna Vinschen:
> > On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> > > On Tue, 1 Dec 2020 19:13:39 -0500
> > > Ken Brown via Cygwin wrote:
> > > > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > > > Hello,
> > > > >
>
Am 02.12.2020 um 15:05 schrieb Corinna Vinschen:
On Dec 2 13:39, Takashi Yano via Cygwin wrote:
On Tue, 1 Dec 2020 19:13:39 -0500
Ken Brown via Cygwin wrote:
On 12/1/2020 4:24 AM, Mattl Mario wrote:
Hello,
Since cygwin1.dll version 3.1.5, I observed the following behavior:
If a symbolic
On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> On Tue, 1 Dec 2020 19:13:39 -0500
> Ken Brown via Cygwin wrote:
> > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > Hello,
> > >
> > > Since cygwin1.dll version 3.1.5, I observed the following behavior:
> > > If a symbolic link is existing in the P
On Tue, 1 Dec 2020 19:13:39 -0500
Ken Brown via Cygwin wrote:
> On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > Hello,
> >
> > Since cygwin1.dll version 3.1.5, I observed the following behavior:
> > If a symbolic link is existing in the PATH environment, programs (external
> > from Cygwin's system
On 12/1/2020 4:24 AM, Mattl Mario wrote:
Hello,
Since cygwin1.dll version 3.1.5, I observed the following behavior:
If a symbolic link is existing in the PATH environment, programs (external from
Cygwin's system directory) using cygwin1.dll cannot be executed anymore.
Possibly, because the Cygw
On Sep 8 21:21, Corinna Vinschen wrote:
> On Sep 8 11:28, L A Walsh wrote:
> >
> >
> > On 9/8/2020 12:18 AM, Corinna Vinschen wrote:
> > > On Sep 7 14:34, L A Walsh wrote:
> > >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/
> > >>>
> > >>> Please give them a try.
> >
On Sep 8 11:28, L A Walsh wrote:
>
>
> On 9/8/2020 12:18 AM, Corinna Vinschen wrote:
> > On Sep 7 14:34, L A Walsh wrote:
> >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/
> >>>
> >>> Please give them a try.
> >> ---
> >> Got:
> >>
> >> "The procedure entry point uname
On Sep 8 20:47, Thomas Wolff wrote:
>
>
> Am 08.09.2020 um 20:28 schrieb L A Walsh:
> >
> > On 9/8/2020 12:18 AM, Corinna Vinschen wrote:
> > > On Sep 7 14:34, L A Walsh wrote:
> > > > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/
> > > > >
> > > > > Please give them
Am 08.09.2020 um 20:28 schrieb L A Walsh:
On 9/8/2020 12:18 AM, Corinna Vinschen wrote:
On Sep 7 14:34, L A Walsh wrote:
I uploaded new snapshots for testing to https://cygwin.com/snapshots/
Please give them a try.
For me, the snapshot dll fixes the issue I observed.
Thomas
---
Got:
"
On 9/8/2020 12:18 AM, Corinna Vinschen wrote:
> On Sep 7 14:34, L A Walsh wrote:
>>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/
>>>
>>> Please give them a try.
>> ---
>> Got:
>>
>> "The procedure entry point uname_x could not be located in the dynamic
>> link library
On Sep 7 14:34, L A Walsh wrote:
>
> >
> > I uploaded new snapshots for testing to https://cygwin.com/snapshots/
> >
> > Please give them a try.
> ---
> Got:
>
> "The procedure entry point uname_x could not be located in the dynamic
> link library cygwin1.dll"
>
> :-(
uname_x is exported jus
Hi,
I tried cygpath but it did not help. It gave me folder path as given below.
I used this path but results were the same.
"/proc/cygdrive/c/delit/Rdiff/العَرَبِيَّة.txt"
Anyways half my problem is solved as now with the latest Cygwin I can get
RDiff.exe to work fine, but it only happens if I e
Greetings, Allan Fernandes!
> I am using cygwin1.dll (windows 7) and running a batch file (Abc.Bat) code
> given below with observation messages.
> Problem:
> cygwin1.dll (ver 1.7)+Rdiff.exe handles Unicode but does not handle UNC
> paths.
> cygwin1.dll (ver 2.10)+Rdiff.exe does not handle Unic
On Jan 25 00:31, Ozgun Altunkaya wrote:
> Hello. So I'm trying to install Cygwin64 on my Win 8.1. During the
> installation, I got an error saying postinstall script error, and only
> packages I chose are the recommended ones and lynx. After the
> installation, I tried to open Cygwin 64, but got an
Corinna Vinschen writes:
> On November 18, 2014 12:54:22 PM CET, Olumide wrote:
> >Thanks Corinna.
> >
> >My application does not explicitly use XSI IPC functions. It's an
> >ordinary C++ application compiled with gcc.
>
> Your app calls shmat, either the exe or some DLL.
>
> >BTW, are ZN4muto7re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On November 18, 2014 12:54:22 PM CET, Olumide wrote:
>Thanks Corinna.
>
>My application does not explicitly use XSI IPC functions. It's an
>ordinary C++ application compiled with gcc.
Your app calls shmat, either the exe or some DLL.
>BTW, are ZN4m
Thanks Corinna.
My application does not explicitly use XSI IPC functions. It's an
ordinary C++ application compiled with gcc.
BTW, are ZN4muto7releaseEP7_cygtls and ZN4muto7acquireEm also XSI function?
Regards,
- Olumide
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Nov 18 01:05, Olumide wrote:
> On 18/11/2014 00:45, Olumide wrote:
> >According to the AMD CodeXL profiler, the modules cygwin1.dll and
> >cygstdc++-6.dll account for 65.67% and 5.13% respectively of the runtime
> >of my code. The breakdown is shown below:
>
> Reposting breakdown (hopefully wil
Just a guess : http://linux.die.net/man/2/shmat
Maybe your code needs to optimize around memory abit.
On Mon, Nov 17, 2014 at 5:05 PM, Olumide <50...@web.de> wrote:
>
> On 18/11/2014 00:45, Olumide wrote:
>>
>> According to the AMD CodeXL profiler, the modules cygwin1.dll and
>> cygstdc++-6.dll a
On 18/11/2014 00:45, Olumide wrote:
According to the AMD CodeXL profiler, the modules cygwin1.dll and
cygstdc++-6.dll account for 65.67% and 5.13% respectively of the runtime
of my code. The breakdown is shown below:
Reposting breakdown (hopefully will be less mangled this time)
Function
On Dec 8 15:10, Tim Prince wrote:
> 1.27.7 from sourceware mirror not working with gcc nor gfortran for
> me.
-v?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp8yfFdg2UKj.pgp
Descript
> On Sun, Jul 07, 2013 at 05:34:16PM +0200, Henri wrote:
>>Btw, cygcheck -s still shows on error output:
>>
>>cygcheck: Wrong architecture. Only ix86 executables supported. (8 times).
>
> Several people have reported that here and I've noticed it myself. This
> report was due to the fact that are
On Sun, Jul 07, 2013 at 05:34:16PM +0200, Henri wrote:
>Btw, cygcheck -s still shows on error output:
>
>cygcheck: Wrong architecture. Only ix86 executables supported. (8 times).
Several people have reported that here and I've noticed it myself. This
report was due to the fact that are several .d
> Hi all,
>
> As far as I can tell !,
> I am experiencing a "process hang" since cygwin 1.7.20, perhaps 1.7.19, if
> bash in used in a DOS box.
>
> - if bash used in mintty: no problem
> - if bash used in DOS box: no problem after having switched back to
>cygwin 1.7.18
>
> Details of "process
Thanks Marco. Thanks Earnie. Thanks Larry. Thanks for your help. I got cygwin
to work and actually ran mutt.
Ciao - Mark.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
[Sent this last night but since it hasn't shown up yet in the archives, I'm
assuming it got lost.]
On 6/24/2013 11:09 PM, Mark Filipak wrote:
c:\Program Files\ISO to USB\cygwin1.dll // 2006-01-20, 1,805,448 bytes
c:\totalcmd\plugins\wcx\TotalISO\cygwin1.dll // 2006-01-20, 1,805,448 bytes
On Tue, Jun 25, 2013 at 8:05 AM, Mark Filipak wrote:
> On 2013/6/25 2:25 AM, marco atzeri wrote:
>>
>>
>> cygwin package is missing, nothing will work without it
>
>
> I'm afraid I don't know what that means. What should I install? What should
> I look for? Where should I look? When I find it, wher
On 2013/6/25 2:25 AM, marco atzeri wrote:
cygwin package is missing, nothing will work without it
I'm afraid I don't know what that means. What should I install? What should I
look for? Where should I look? When I find it, where would I copy it?
Il 6/25/2013 5:09 AM, Mark Filipak ha scritt
Il 6/25/2013 5:09 AM, Mark Filipak ha scritto:
Hello,
I'm brand new and shiny. I'm attempting to install cygwin in order to
install and run mutt. I have no experience with either of them. I have
no idea whether cygwin and mutt are what I need. I'll learn by doing.
It appears that cygwin failed
> But then what is "julius-3.5.2-quickstart-windows"? It's not the usual
>place for a Cygwin installation... it does sound like you have two of them,
>one shipped as part of whatever julius is (presumably a port of something
from
>linux)?
julius is an open source speech recognition tool. If yo
On 13/04/2010 17:19, gothrg wrote:
> I hope someone can help me with this error. It is getting highly annoying
> to restart my laptop when this happens. It is when I am using cygwin
> commands in DOS that normally messes it up.
>
> I have followed these instructions from the error below and hav
On Mar 29 17:25, Matthew Kidd wrote:
> On Mar 22 10:31, Corinna Vinschen wrote:
> >>> I have no problem running your test case with Windows 7 64 and the
> >>> latest Cygwin from CVS.
> >>
> >> Did you check using a very large file? What I have learned on the
> >> 64-bit...
> >
> > I tested with a
On Mar 22 10:31, Corinna Vinschen wrote:
>>> I have no problem running your test case with Windows 7 64 and the
>>> latest Cygwin from CVS.
>>
>> Did you check using a very large file? What I have learned on the
>> 64-bit...
>
> I tested with a compressed Fedora 11 ISO file. Original size
> 36838
On Mar 22 14:59, Matthew Kidd wrote:
> > I have no problem running your testcase with Windows 7 64 and the
> > latest Cygwin from CVS.
>
> Did you check using a very large file? What I have learned on the 64-bit
I tested with a compressed Fedora 11 ISO file. Original size
3683829760 bytes, compr
>> >> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003
>> >> and immediately ran into trouble. It seems that Perl can no
>> >> longer shutdown pipes related to Cygwin executables. Here is
>> >> some example code:
>> >>
>> >> #!/usr/bin/perl
>> >>
>> >> use strict;
>> >>
>> >> # my $f
On Mar 19 15:13, Matthew Kidd wrote:
> >> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003 and
> >> immediately ran into trouble. It seems that Perl can no longer
> shutdown
> >> pipes related to Cygwin executables. Here is some example code:
> >>
> >> #!/usr/bin/perl
> >>
> >> use st
>> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003 and
>> immediately ran into trouble. It seems that Perl can no longer
shutdown
>> pipes related to Cygwin executables. Here is some example code:
>>
>> #!/usr/bin/perl
>>
>> use strict;
>>
>> # my $fname = 'Y:\path\to\ratherbigfile
On Mar 18 16:16, Matthew Kidd wrote:
> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003 and immediately
> ran into trouble. It seems that Perl can no longer shutdown pipes related to
> Cygwin executables. Here is some example code:
>
> #!/usr/bin/perl
>
> use strict;
>
> # my $fname
Follow-up:
I can confirm that your example using rsync to fetch a remote tree also
fails on my system.
I built a work-around into cygwin1.dll that solves the first failure
cases in which socketpair() is involved on a system-wide basis, so
individual applications don't have to be patched. The pr
For the sake of completeness...
I wrote:
May you give some more details? For example, should I rebuild under
Cygwin-1.5 or 1.7? with cygport (but which uses rsync, sigh!)? which
patch to apply?...
I have rebuilt rsync-3.05 both on Cygwin-1.5 and 1.7 applying this patch:
--- util.c.orig 2008-
Karl (alias cygwin) wrote:
A way to find the answer would be to recompile your rsync without socketpair
support (as shown in my previous message)
and retry your test case.
May you give some more details? For example, should I rebuild under
Cygwin-1.5 or 1.7? with cygport (but which uses rsync
Corinna Vinschen wrote:
On Aug 14 00:07, Angelo Graziosi wrote:
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is the discussion in this thread related to
what I flagged here:
http://cygwin.com/ml/cygwin/2007-04/msg00143.
http://cygwin.com/acronyms/#TOFU
On Aug 14 00:44, cygwin wrote:
> Further tests with this little program show that the observed error only
> occurs when the socket is dup()'ed to STDIN (fd = 0), but not when
> dup'ed to any other fd number. To test, replace STDIN_FILENO in the dup
> call
On Aug 14 00:07, Angelo Graziosi wrote:
> Christopher Faylor wrote:
>
>> "Socket operation on non-socket" sounds like the problem that
>
> I am just a little curious, is the discussion in this thread related to
> what I flagged here:
>
> http://cygwin.com/ml/cygwin/2007-04/msg00143.html
>
> and her
Further tests with this little program show that the observed error only
occurs when the socket is dup()'ed to STDIN (fd = 0), but not when
dup'ed to any other fd number. To test, replace STDIN_FILENO in the dup
call with any positive integer (except 3 and 4).
Also, explicitly closing STDIN in a
I forgot to add that the same binary copy of the executable of the test
program (compiled under 1.7) works without error if I place the
cygwin1.dll version 1.5 into the same directory.
cygwin wrote:
I wrote a small test program to isolate the problem from RSYNC.
The problem occurs when a fil
I wrote a small test program to isolate the problem from RSYNC.
The problem occurs when a file descriptor obtained from socketpair() is
dup2()'ed into STDIN and then closed. The close call fails.
Output from the program is as follows:
socket 1 = 3
socket 2 = 4
dup2 socket 1...
closing socket
A way to find the answer would be to recompile your rsync without
socketpair support (as shown in my previous message)
and retry your test case.
Angelo Graziosi wrote:
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is the discussion in this thread related to
what I flagged here:
http://cygwin.com/ml/cygwin/2007-04/msg00143.html
and here:
http://cygwin.com/ml/cygwin/2007-05/msg00677.html
After updating 2 other systems to cygwin 1.7, I find that they also work
fine in the same test.
However, that doesn't help much debugging this.
I found that the problem on the failing system is related to using Unix
domain sockets for the IPC pipes.
If I replace the socketpair() call in fd_p
Christopher Faylor cygwin.com> writes:
> >often this type of bug reappears, too - historical cygwin has had it in
> >the past with newlib's popen implementation (I fixed it 2006-08-22), as
>
> Just a point of order: Cygwin doesn't use the newlib version of
> popen.
It doesn't now, but did prior
On Thu, Aug 13, 2009 at 07:52:01PM +, Eric Blake wrote:
>cygwin sipxx.com> writes:
>
>>
>> - if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
>> - close(to_child_pipe[1]) < 0 ||
>> - close(from_child_pipe[0]) < 0 ||
>> - dup2(
cygwin sipxx.com> writes:
>
> - if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
> - close(to_child_pipe[1]) < 0 ||
> - close(from_child_pipe[0]) < 0 ||
> - dup2(from_child_pipe[1], STDOUT_FILENO) < 0) {
> -
On Thu, Aug 13, 2009 at 08:30:53PM +0200, Corinna Vinschen wrote:
>On Aug 13 13:17, cygwin wrote:
>>The RSYNC application fails in close() on the pipe streams to and from
>>child processes created when rsync starts. When running rsync.exe and
>>cygwin1.dll from cygwin 1.5 within the 1.7 installati
On Aug 13 13:17, cygwin wrote:
> The RSYNC application fails in close() on the pipe streams to and from
> child processes created when rsync starts.
> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
> installation on the same system (WinXP pro),
> the identical invocation
cygwin wrote:
> The RSYNC application fails in close() on the pipe streams to and from
> child processes created when rsync starts.
> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
> installation on the same system (WinXP pro),
> the identical invocation completes without err
I have it happen to me that something puts a cygwin dll in my system dir and
sets it hidden and/or system. Go to your windows dir in a command prompt and
say "attrib cygwin1.dll /s"
"Affan Ahmed" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
So here is the deal, I am trying to r
Affan Ahmed wrote:
So here is the deal, I am trying to run cygwin through poderosa, and I
always get the error saying that "procedure entry point _fopen64 could
not be located in the dll cygwin1.dll"
This suggests you have a *really* old version of cygwin1.dll loaded in
memory. If true, sounds
Reply to the mailing list, not to me.
[EMAIL PROTECTED] wrote:
> Hi Brian thank you very much for your answer.
> Why then, when I build with borland say, there is no such dependancy and I
> can just give that exe to anyone and it just works?
It still has a dependency on a C runtime library, it'
"Charles D. Russell" wrote:
> > You don't. Or you use something other than Cygwin.
>
> Not as drastic as it sounds. Look at the compiler flag -mno-cygwin.
> Very handy if you occasionally want to distribute executables without
> cygwin1.dll.
That would fall under "use something other than Cygw
Brian Dessent wrote:
sroberts82 wrote:
Can someone help me understand this, its probably really straightforward but
I can't find an answer for this.
Why is it when I build the most basic helloworld.exe and try and run it I
get told of a dependancy on cygwin1.dll? Why do I need this dll, and wha
sroberts82 wrote:
> Can someone help me understand this, its probably really straightforward but
> I can't find an answer for this.
> Why is it when I build the most basic helloworld.exe and try and run it I
> get told of a dependancy on cygwin1.dll? Why do I need this dll, and what
When you buil
On Aug 24 10:49, Eric Blake wrote:
> As a side effect of your change, open("broken_symlink", O_RDWR|O_EXCL) now
> fails with EACCES instead of ENOENT, but since POSIX leaves O_EXCL without
> O_CREAT as undefined behavior.
That's why I didn't add any further testing for other cases with O_EXCL.
Isn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 8/24/2007 8:56 AM:
>> According to POSIX, this should have failed with EEXIST, and oops should
>> not have been created.
>
> If I understand this right, it means that O_EXCL implies not following
> symlinks. I've appl
On Aug 24 07:25, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I finally found root cause for the tar issue reported here:
> http://cygwin.com/ml/cygwin/2007-08/msg00553.html
>
> $ cat foo.c
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
Hi cgf,
> You must be referring to newlib if you are talking about Makefile.am.
> newlib has its own mailing list newlib at sourceware PERIOD org .
> You'll need to talk to the maintainer of newlib if you are adding a new
> function there.
I have contacted the newlib maintainer about the patch, t
On Thu, Jun 07, 2007 at 09:30:22AM -0400, Olivier Langlois wrote:
>Hi,
>
>I wanted to add the function strcasestr() from glibc to the cygwin's libc
>and I have encountered a serie of difficulties and questions. Some of them
>are related to the process of offering changes to cygwin but I will reserv
On Fri, Apr 20, 2007 at 10:06:48AM -0600, Eric Blake wrote:
>According to David Xiao on 4/20/2007 9:49 AM:
>>In win32 sub-system there is no signal or sig-stack facilities. I am
>>quite curious how cygwin1.dll can do that? What's the mysterious part
>>of it?
>>
>>As I knew, user-mode thread libra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to David Xiao on 4/20/2007 9:49 AM:
> In win32 sub-system there is no signal or sig-stack facilities. I am quite
> curious how cygwin1.dll can do that? What's the mysterious part of it?
>
> As I knew, user-mode thread library such as pthrea
On Sun, 1 Apr 2007 00:53:40 -0400, Christopher Faylor
I hope the date is the most relevant part of this posting.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
On Apr 2 07:13, Christopher Faylor wrote:
> On Mon, Apr 02, 2007 at 09:57:28AM +0200, Corinna Vinschen wrote:
> >On Apr 1 00:53, Christopher Faylor wrote:
> >> After some intense discussion with Corinna, we've decided that we will
> >> soon be removing all support for any version of Windows other
On Mon, Apr 02, 2007 at 09:57:28AM +0200, Corinna Vinschen wrote:
>On Apr 1 00:53, Christopher Faylor wrote:
>> After some intense discussion with Corinna, we've decided that we will
>> soon be removing all support for any version of Windows other than
>> Windows Vista 64.
>
>Sorry folks, Chris is
On Apr 1 00:53, Christopher Faylor wrote:
> After some intense discussion with Corinna, we've decided that we will
> soon be removing all support for any version of Windows other than
> Windows Vista 64.
Sorry folks, Chris isn't quite up-to-date with Vista versions.
*Of course* Cygwin will only r
On 02 April 2007 08:18, Roelf Renkema wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Christopher Faylor wrote:
>> On Sun, Apr 01, 2007 at 08:03:58PM +0100, Roelf Renkema wrote:
On Sun, Apr 01, 2007 at 08:58:48AM +0100, Roelf Renkema wrote:
> Christopher Faylor wrote:
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor wrote:
> On Sun, Apr 01, 2007 at 08:03:58PM +0100, Roelf Renkema wrote:
>>> On Sun, Apr 01, 2007 at 08:58:48AM +0100, Roelf Renkema wrote:
Christopher Faylor wrote:
> After some intense discussion with Corinna, we've decided
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Igor Peshansky wrote:
> On Sun, 1 Apr 2007, Roelf Renkema wrote:
>
>> Igor Peshansky wrote:
>>
>>> Who said it was a gag? Did you even try running the latest snapshot
>>> on Win2k or WinXP?
>> You mean that was cygwin? Damn I reinstalled win2k, xp an
From: Christopher Faylor
After some intense discussion with Corinna, we've decided that we will
soon be removing all support for any version of Windows other than
Windows Vista 64.
Will the Wii version be split out into a Cygwii project?
On Sun, Apr 01, 2007 at 04:08:46PM -0400, Igor Peshansky wrote:
>On Sun, 1 Apr 2007, Roelf Renkema wrote:
>
>> Igor Peshansky wrote:
>>
>> > Who said it was a gag? Did you even try running the latest snapshot
>> > on Win2k or WinXP?
>>
>> You mean that was cygwin? Damn I reinstalled win2k, xp and
On Sun, 1 Apr 2007, Roelf Renkema wrote:
> Igor Peshansky wrote:
>
> > Who said it was a gag? Did you even try running the latest snapshot
> > on Win2k or WinXP?
>
> You mean that was cygwin? Damn I reinstalled win2k, xp and 2003 twice
> this afternoon because I was blaming MS.
Heh, you should h
On Sun, Apr 01, 2007 at 08:03:58PM +0100, Roelf Renkema wrote:
>>On Sun, Apr 01, 2007 at 08:58:48AM +0100, Roelf Renkema wrote:
>>>Christopher Faylor wrote:
After some intense discussion with Corinna, we've decided that we will
soon be removing all support for any version of Windows other t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Igor Peshansky wrote:
> Who said it was a gag? Did you even try running the latest snapshot on
> Win2k or WinXP?
You mean that was cygwin? Damn I reinstalled win2k, xp and 2003 twice
this afternoon because I was blaming MS. I hate this. I'm agains t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I've blocked you from sending any further inane tripe to this list. I
> don't need to hear this.
>
Don't be silly.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DB
On Sun, Apr 01, 2007 at 08:58:48AM +0100, Roelf Renkema wrote:
>Christopher Faylor wrote:
>>After some intense discussion with Corinna, we've decided that we will
>>soon be removing all support for any version of Windows other than
>>Windows Vista 64.
>>
>Doesn't even make the impression of an apri
Jeff Hawk wrote:
That's why I am afraid; his email is time stamped 6 minutes before April 1st
:(
No - according to raw mail header, local time was:
"Date: Sun, 1 Apr 2007 00:53:40 -0400"
(But this might not be true due to some Windows DST Bug.
The existence of such a bug is unfortunatel
That's why I am afraid; his email is time stamped 6 minutes before April 1st
:(
--Jeff
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Markus Schönhaber
> Sent: Sunday, April 01, 2007 7:27 AM
> To: cygwin@cygwin.com
> S
On Sun, 1 Apr 2007, Roelf Renkema wrote:
> Christopher Faylor wrote:
> > After some intense discussion with Corinna, we've decided that we will
> > soon be removing all support for any version of Windows other than
> > Windows Vista 64.
>
> Doesn't even make the impression of an april fools gag. Y
1 - 100 of 252 matches
Mail list logo
