yangbo@YANGBOI5 ~
$ cygcheck -s -v -r
Cygwin Configuration Diagnostics
Current System Time: Tue Jun 25 15:27:31 2013
Windows 7 Ultimate Ver 6.1 Build 7601 Service Pack 1
Running under WOW64 on AMD64
Path: C:\cygwin\home\yangbo\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
On Jun 25 22:37, Atry wrote:
[...]
$ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
ab__eA___E
Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed in
the C locale:
$ LANG=C echo abcdeABCDE | sed -e 's/[B-D]/_/g'
The character ordering is based on the default Windows ordering for
Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed
in the C locale:
I'm not quite sure it applies here. I'm using US English Windows 7.
LANG = 'en_US.UTF-8'
I get the same result:
$ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
ab__eA___E
BUT:
$ echo abcdeABCDE | LANG=C sed
The character ordering is based on the default Windows ordering for the
locale, and that's dictionary ordering, apparently.
Ah, I see what you meant here. There's an elaborated explanation:
http://www.gnu.org/software/gawk/manual/html_node/Ranges-and-Locales.html
Anton Lavrentiev
Contractor
On Jun 25 15:38, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed
in the C locale:
I'm not quite sure it applies here. I'm using US English Windows 7.
LANG = 'en_US.UTF-8'
I get the same result:
$ echo abcdeABCDE |
Lavrentiev, Anton sent the following at Tuesday, June 25, 2013 11:44 AM
The character ordering is based on the default Windows ordering for the
locale, and that's dictionary ordering, apparently.
Ah, I see what you meant here. There's an elaborated explanation:
On Jun 25 18:03, Corinna Vinschen wrote:
On Jun 25 15:38, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Your locale is zh_CN.UTF-8. What you're expecting is only guaranteed
in the C locale:
I'm not quite sure it applies here. I'm using US English Windows 7.
LANG = 'en_US.UTF-8'
to acknowledge my
existence?
Much obliged,
jik
-Original Message-
From: Jonathan Kamens [jik at kamens dot us]
Sent: Friday, January 07, 2011 11:22 AM
To: cygwin at cygwin dot com
Subject: RE: Bug report for run.exe with patch
ACK?
-Original Message-
From: Jonathan Kamens [jik
On 1/20/2011 8:04 PM, Jonathan Kamens wrote:
This is a bug in a program that is installed and used in pretty much every
single Cygwin installation in the world.
Other people have reported encountering the bug.
I've identified the bug and provided a patch, three weeks ago.
Can I please get
Several people have reported problems with run.exe complaining about being
unable to execute programs.
The typical symptoms of the problem are that the user clicks on a link in
the Start menu that uses run.exe and gets back an error pop-up from run.exe
that looks like this:
Error could not start
Hi,
I have a problem with cygwin and procmail. If messages exceed a certain
size, procmail just hangs, eating 100% cpu without doing anything.
I've been trying to debug this further, but it just hangs, even with an
empty .procmailrc file.
Funny enough if I run procmail from within strace it
Sec,
On Thu, Jul 08, 2010 at 03:00:21PM +0200, Stefan `Sec` Zehl wrote:
I have a problem with cygwin and procmail. If messages exceed a
certain size, procmail just hangs, eating 100% cpu without doing
anything.
I've been trying to debug this further, but it just hangs, even with an
empty
On Jun 21 14:22, Linda Walsh wrote:
I have two accounts on my client machine. One is m...@workstation,
the other is m...@domain. They are both me and I need to have them
be able access each other's files mostly transparently.
As a result, in windows, I setup a group (megroup) that contains
I have two accounts on my client machine. One is m...@workstation,
the other is m...@domain. They are both me and I need to have them
be able access each other's files mostly transparently.
As a result, in windows, I setup a group (megroup) that contains both
me and me!
There is a similar post from 2009 where the conclusion is that this
can be caused by very deep forking
(http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it
possible that the make script does very deep, or is stuck in infinite,
recursion?
On 6/8/10, Nasser M. Abbasi n...@12000.org
Err, 'very deep' was a bit misleading, the error seemed to show up at
2-3 levels according to the last post in that thread.
On 6/8/10, Alexander T mittspamko...@gmail.com wrote:
There is a similar post from 2009 where the conclusion is that this
can be caused by very deep forking
On 6/8/2010 12:46 AM, Alexander T wrote:
There is a similar post from 2009 where the conclusion is that this
can be caused by very deep forking
(http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it
possible that the make script does very deep, or is stuck in infinite,
recursion?
On Jun 8 00:54, Nasser M. Abbasi wrote:
On 6/8/2010 12:46 AM, Alexander T wrote:
There is a similar post from 2009 where the conclusion is that this
can be caused by very deep forking
(http://readlist.com/lists/cygwin.com/cygwin/6/34359.html). Is it
possible that the make script does very
On 6/8/2010 1:25 AM, Corinna Vinschen wrote:
Your bug is something else.
I'm still waiting for some helpful debugging like an strace or, even
better, a simple testcase in plain C.
Corinna
If someone using windows 7 out there, can install Latex2html with the
current cygwin, they should be
On Mon, Jun 07, 2010 at 11:48:54AM -0700, Nasser M. Abbasi wrote:
This is a bug report. attached is output of cygcheck -s -v -r (I get
some access denited warnings btw):
$ cygcheck -s -v -r cygcheck.out
/usr/bin/cygrunsrv: warning: OpenService failed for 'DcomLaunch': Win32
error 5
Access
On 6/7/2010 12:41 PM, Christopher Faylor wrote:
On Mon, Jun 07, 2010 at 11:48:54AM -0700, Nasser M. Abbasi wrote:
This is a bug report. attached is output of cygcheck -s -v -r (I get
some access denited warnings btw):
$ cygcheck -s -v -r cygcheck.out
/usr/bin/cygrunsrv: warning: OpenService
On Mon, Jun 07, 2010 at 12:59:51PM -0700, Nasser M. Abbasi wrote:
On 6/7/2010 12:41 PM, Christopher Faylor wrote:
On Mon, Jun 07, 2010 at 11:48:54AM -0700, Nasser M. Abbasi wrote:
This is a bug report. attached is output of cygcheck -s -v -r (I get
some access denited warnings btw
On 6/7/2010 1:15 PM, Christopher Faylor wrote:
Rather than express amazement that I raised the issue why not just prove
that this doesn't mean anything by simplifying your path and trying
again?
I am not expressing amazement, I was asking a simple question, if one
can't install windows perl
On 6/7/2010 4:34 PM, Nasser M. Abbasi wrote:
On 6/7/2010 1:15 PM, Christopher Faylor wrote:
Rather than express amazement that I raised the issue why not just prove
that this doesn't mean anything by simplifying your path and trying
again?
I am not expressing amazement, I was asking a simple
for 'RpcSs': Win32 error 5
Access is denied.
$
As Larry suggests, I wasn't referring to the cygcheck warnings. I was
referring to your bug report.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com
On 6/7/2010 2:13 PM, Larry Hall (Cygwin) wrote:
Chris wasn't asking you to try this to see if the cygcheck warnings would
go away. He was asking you to try this to see if it made any difference
with your original problem.
OK, I just did. The perl crash is still there.
Please let me know
On 6/7/2010 8:49 PM, Nasser M. Abbasi wrote:
$ make test
0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error -
Internal error: TP_NUM_W_BUFS too small.
Error while converting image: No such file or directory
Error: Cannot read 'img2.png': No such file or directory
On 6/7/2010 7:03 PM, Charles Wilson wrote:
On 6/7/2010 8:49 PM, Nasser M. Abbasi wrote:
$ make test
0 [main] perl 5308 C:\cygwin\bin\perl.exe: *** fatal error -
Internal error: TP_NUM_W_BUFS too small.
Error while converting image: No such file or directory
Error: Cannot read
On 08/04/2010 04:47, Mark Lillibridge wrote:
Can you pull this patch and include it in the next X server release,
please.
Excellent. Thank you. Do we need to do anything special for this
to get picked up for Xming as well?
Assuming I don't receive too much hatemail
On 08/04/2010 04:47, Mark Lillibridge wrote:
Can you pull this patch and include it in the next X server release, please.
Excellent. Thank you. Do we need to do anything special for this
to get picked up for Xming as well?
Assuming I don't receive too much hatemail about this breaking
Jon wrote:
Yaakov,
Can you pull this patch and include it in the next X server release, please.
Excellent. Thank you. Do we need to do anything special for this
to get picked up for Xming as well?
- Mark
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem
On 20/03/2010 16:32, Mark Lillibridge wrote:
On February 23, 2010, Jon Turney wrote:
On 13/02/2010 20:24, Mark Lillibridge wrote:
Jon wrote:
Thanks for the patch. Have you actually tested that this resolves your
problem?
Yes. Of course, really, really large bursts will still
On February 23, 2010, Jon Turney wrote:
On 13/02/2010 20:24, Mark Lillibridge wrote:
Jon wrote:
Thanks for the patch. Have you actually tested that this resolves your
problem?
Yes. Of course, really, really large bursts will still fail, but
they should be very rare.
On 13/02/2010 20:24, Mark Lillibridge wrote:
Jon wrote:
Thanks for the patch. Have you actually tested that this resolves your
problem?
Yes. Of course, really, really large bursts will still fail, but
they should be very rare.
Perhaps you might try the attached patch, instead,
Jon wrote:
Thanks for the patch. Have you actually tested that this resolves your
problem?
Yes. Of course, really, really large bursts will still fail, but
they should be very rare.
I'll add some words about contributing patches to the CG guide
documentation,
thanks for
fix up of the text. Note
that what is really dropped are key events so the system can get into
the state where the shift key remains pressed or a key starts repeating
forever because the key up event was dropped.
[repro snipped]
Mark,
Thanks for the detailed bug report and clear reproduction
Given there doesn't seem to be anyone competent enough to attempt a
more ambitious patch, I think we should apply the temporary patch. How
should we/I. go about doing this? The Cygwin X website and contributors
documentation doesn't actually say how to do this.
The patch is enclosed at
I've done a bit more investigating.
It appears that winWindowProc can block at the cost of preventing
processing of any Windows messages until it returns. Does anyone know
how fast the mieq queue drains? If this isn't very fast, then having
winWindowProc block waiting for the mieq queue is
On 2010-02-01 12:33 AM, Mark Lillibridge wrote:
I've done a bit more investigating.
It appears that winWindowProc can block at the cost of preventing
processing of any Windows messages until it returns. Does anyone know
how fast the mieq queue drains? If this isn't very fast, then having
Dennis wrote:
Hi Mark.
I am a bit new to this list, but not THAT new to programming. If you don't
know how many keystrokes you need to have a buffer for, then you have 2
choices:
1. Have a ridiculously huge buffer.
2. Setup a dynamic array.
Using a 25000 character buffer seems
Larry Hall wrote:
On 01/19/2010 01:17 PM, Mark Lillibridge wrote:
Hi.
I don't appear to have gotten any response to my message sent to
this list January 12 (copied below). Do I have the right list? Am I
supposed to use a different mechanism to report bugs
Hi.
I don't appear to have gotten any response to my message sent to
this list January 12 (copied below). Do I have the right list? Am I
supposed to use a different mechanism to report bugs with the Cygwin X
server? Please help.
- Thanks,
Mark
Background:
I use
On 01/19/2010 01:17 PM, Mark Lillibridge wrote:
Hi.
I don't appear to have gotten any response to my message sent to
this list January 12 (copied below). Do I have the right list? Am I
supposed to use a different mechanism to report bugs with the Cygwin X
server? Please help.
Thanks
Background:
I use Nuance's Dragon NaturallySpeaking voice recognition software
to control remote Linux systems from a Windows box. I open up xterms
and emacs windows on a local Cygwin X server. Occasionally the voice
recognizer makes a mistake, which has to be corrected. The mechanics of
On Dec 16 16:36, Edward Strauch wrote:
I'm running Cygwin 1.7 Beta on Windows 7, and have encountered the
following problem with the openssh-5.3p1.1 package:
There is no ssh-copy-id file or man page. I can find these files in the
source package (openssh-5.3p1-1-src), but not in the binary
I'm running Cygwin 1.7 Beta on Windows 7, and have encountered the
following problem with the openssh-5.3p1.1 package:
There is no ssh-copy-id file or man page. I can find these files in the
source package (openssh-5.3p1-1-src), but not in the binary package.
--
Problem reports:
If you add a \ to the end of the download path with the 1.7 installer,
packages fail to download properly and the installer terminates with an
error. I finally realized it was just an amateur mistake in the
installer code and tried it without the \, and it worked fine. Adding a
\ works in the
Derek Kalweit wrote:
If you add a \ to the end of the download path with the 1.7 installer,
packages fail to download properly and the installer terminates with an
error. I finally realized it was just an amateur mistake in the
installer code and tried it without the \, and it worked fine.
Dave Korn wrote:
Derek Kalweit wrote:
If you add a \ to the end of the download path with the 1.7 installer,
packages fail to download properly and the installer terminates with an
error. I finally realized it was just an amateur mistake in the
installer code and tried it without the \, and
systems and gotten results similar to those in
bug_cygwin.out; i.e., the assert
assertion r != 0 failed
I have run the same command on several Linux systems and
gotten results similar to those in bug_linux.out; i.e., no assertion.
bug.sh
Description: bash shell script
BUG REPORT: Cygwin
Brad Bell wrote:
I seem to have run across a bug using g++ with -O2 under Cygwin. It has
to do with using static class member functions and standard string.
The bash shell script command
./bug.sh
creates three files, compiles, links, and runs the result. I have run
this command on
This is a reply to the message
http://cygwin.com/ml/cygwin/2007-10/msg00508.html
where the following request was made
Can you post the bug{1,2}.cpp files ?
Note that the original bug report is at
http://cygwin.com/ml/cygwin/2007-10/msg00507.html
I am attaching the requested
that the problem is not just multiple in-line expansions, but the fact
that there is no obvious home compilation unit for this header-only
class. The following variant on Brad's example shows this:
-- Cut Here test2.sh ---
#! /bin/bash
#
echo A Cygwin g++ -O2 Bug Report
Can you post the bug{1,2}.cpp files? I would guess that its not a bug,
but rather you are relying on an undefined order of static
initialization that happens to do what you want sometimes but not
others. It's impossible to say for sure without seeing the source files,
though.
Oh I see, you
On Wed, Oct 24, 2007 at 12:21:27PM -0700, Robert P. Goddard wrote:
This is a reply to the message
Yo! Just reply to the message. You don't have to announce that you're
doing it.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Hi
I experienced the following problem on the attempt to
install the ioperm.sys driver with the setup comand
ioperm -i -v
on a Windows Server 2003 R2 SP2 x64 DC machine
(2 x AMD Opteron Server with 4GB RAM, fully patched)
a) In the command window, the ioperm installer reports
[EMAIL PROTECTED] wrote:
\??\C:\cygwin\bin\ioperm.sys has been blocked from loading due to
incompatibility
with this system. Please contact your software vendor for a compatible
version of
the driver.
Yes, there's no way a 32 bit driver should work in a 64 bit OS.
Suggestion:
* From: Robert Peaslee peasleer at gmail dot com
* To: cygwin at cygwin dot com
* Date: Fri, 16 Mar 2007 17:19:18 -0400
* References:
[EMAIL PROTECTED]
Thrall, Bryan wrote:
Yes, WinXP stores your username twice (Full name and User Name) and
Cygwin uses the hidden one
. This problem occurred as a result of my changing all my
usernames with spaces to usernames without spaces to make them Linux
compatible.
I wanted to thank all for the responses. After many reinstallations of
CygWin, I finally identified the problem and got things working. This is
just a bug report
the problem and got things working. This is
just a bug report documenting my discoveries and what I believe is going on.
1. A virgin install of CygWin makes a list of all user names on the
system. This list is reflected in /etc/passwd after any reinstall. I am
guessing this list is stored
. This
is just a bug report documenting my discoveries and what I believe is
going on.
1. A virgin install of CygWin makes a list of all user names on the
system. This list is reflected in /etc/passwd after any reinstall. I
am guessing this list is stored in the Windows XP registry as this
list does
. This
is just a bug report documenting my discoveries and what I believe is
going on.
1. A virgin install of CygWin makes a list of all user names on the
system. This list is reflected in /etc/passwd after any reinstall. I
am guessing this list is stored in the Windows XP registry as this
list does
Robert Peaslee wrote on Friday, March 16, 2007 3:53 PM:
Windows XP stores the first username you choose and will associate
your current username to it regardless of what you change it to.
Cygwin stores nothing, it is asking Windows what your username is and
getting a response of what Windows
Thrall, Bryan wrote:
Yes, WinXP stores your username twice (Full name and User Name) and
Cygwin uses the hidden one (User Name), but I'm pretty sure you
don't have to reinstall XP to change it!
IIRC, you can change the username from Control Panel-User
Accounts-Advanced tab-Advanced
* Robert Peaslee (Fri, 16 Mar 2007 16:52:40 -0400)
Actually, this information is incorrect.
Windows XP stores the first username you choose and will associate your
current username to it regardless of what you change it to. Cygwin
stores nothing, it is asking Windows what your username is
On Fri, Mar 16, 2007 at 10:49:36PM -, Thorsten Kampe wrote:
* Robert Peaslee (Fri, 16 Mar 2007 16:52:40 -0400)
Actually, this information is incorrect.
Windows XP stores the first username you choose and will associate your
current username to it regardless of what you change it to.
Hello.
It must be bug, But Im not sure...
In WinXP all works fine.. but then I use Windows 2003 works strange with
lastest version cygwin1.dll(file version 1.5.19-cr-0x5ef) but works fine with
oldest verstion, like 1.5.18 from 2005.07.02.
Description:
When use SetTimer in Win2003 Application
Hello,
fig2dev version 3.2.4 crashes when converting certain line styles to
latex.
I could reproduce the crash only on Cygwin, on Linux the translation
works somehow
(the line style is apparently not supported and is replaced by the
default one).
Here is the test case:
$ cat
On Fri, 7 Apr 2006, ilya beilin wrote:
Hello,
fig2dev version 3.2.4 crashes when converting certain line styles to
latex.
I could reproduce the crash only on Cygwin, on Linux the
translation works somehow (the line style is apparently not supported
and is replaced by the default one).
FYI, this problem persists in the latest cygwin release. Or as I would
put it, cygwin 1.5.17-1 good, 1.5.19-4 bad. I'll around get to it as
soon as I'm retired, I promise...
Source file 1: == testdll.cpp ==
#include string
std::string test() { return std::string(); }
Source file 2: ==
Stein Somers wrote:
FYI, this problem persists in the latest cygwin release. Or as I would
put it, cygwin 1.5.17-1 good, 1.5.19-4 bad. I'll around get to it as
soon as I'm retired, I promise...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--
Unsubscribe info:
Robert Body wrote:
here is the bug report again, i tried emailing Corinna, but that didn't
work
Like i said I wrote about this a week ago, but nobody replied that yes we
will investigate or yes we will fix it.
Here's a response to your earlier post.
Robert Body wrote:
It could be the 3
here is the bug report again, i tried emailing Corinna, but that didn't work
Delivery to the following recipients failed.
[EMAIL PROTECTED]
From: Robert Body [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: bug with cygwin
Date: Mon, 19 Dec 2005 19:53:48 -0700
Hi, I reported this bug
Robert Body wrote:
here is the bug report again, i tried emailing Corinna, but that didn't
work
As I should have pointed out in my last email message on this subject, you
should always send you bug reports to the list. Most, if not all, maintainers
ask that you do this. This keeps
Hi,
I found a Cygwin time problem which seems to be caused by the Linux API
emulation layer. The actual problem occurred when using the svnserve
process from the Subversion package that comes with Cygwin. After
running more than 49.7 days without rebooting the machine, the time
stamps in the
report this as a bug
http://cs.nyu.edu/~pechtcha/cygwin/setup-2.513-1-alpha.exe
Where should bugs be reported?
Where should potential bugs be discussed? as in, is this a bug:
setup-2.513-1-alpha.exe defaults the Local Package Dir to C:\Program
Files\Mozilla Firefox
^Carl K
--
Carl Karsten [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
report this as a bug
http://cs.nyu.edu/~pechtcha/cygwin/setup-2.513-1-alpha.exe
Where should bugs be reported?
Please post bugs to this list, but be sure to read and follow the
instructions found here:
Carl Karsten wrote:
Where should bugs be reported?
All discussion of the setup.exe program belongs on the cygwin-apps (at)
cygwin.com mailing list, including bug reports.
Where should potential bugs be discussed? as in, is this a bug:
setup-2.513-1-alpha.exe defaults the Local Package Dir
Andreas wrote:
Hello,
I found a bug in the Cygwin environment that blocks me. I condensed the
problem into one C++ file: all.cc
I compiles OK, but crashes, when executed.
I compiled the same file on a LINUX system, it runs there without a problem.
To me it seems that the deallocation in the
Original Message
From: Gerrit P. Haase
Sent: 06 September 2005 18:42
Andreas wrote:
Hello,
I found a bug in the Cygwin environment that blocks me. I condensed the
problem into one C++ file: all.cc
I compiles OK, but crashes, when executed.
$ g++ -Wall -g -o all.C.exe all.C
Andreas wrote:
Hello,
I found a bug in the Cygwin environment that blocks me. I condensed the
problem into one C++ file: all.cc
I compiles OK, but crashes, when executed.
I compiled the same file on a LINUX system, it runs there without a problem.
To me it seems that the deallocation in the
Original Message
From: Gerrit P. Haase
Sent: 06 September 2005 19:06
Ok, after another look I saw that your mailer wrapped the code,
maybe you should change your mailer?
Heh, you _still_ didn't finish reading the thread!
cheers,
DaveK
--
Can't think of a witty
Hello,
I found a bug in the Cygwin environment that blocks me. I condensed the
problem into one C++ file: all.cc
I compiles OK, but crashes, when executed.
I compiled the same file on a LINUX system, it runs there without a problem.
To me it seems that the deallocation in the destructor fails,
Andreas wrote:
I compiled the same file on a LINUX system, it runs there without a problem.
That is a very poor way to assume that your code is correct. When you
make coding errors that trash memory, any one of a number of things can
happen and the outcome completely depends on the compiler,
Hi All
I think the os.popen function in python has recently been broken.
You can see this with the following python code:
import os
fout = os.popen(echo hello)
print fout.read()
On a machine I haven't updated for a little while, I get the expected
result of hello. This
Original Message
From: Nick Burch
Sent: 08 August 2005 11:16
I think the os.popen function in python has recently been broken.
You can see this with the following python code:
import os
fout = os.popen(echo hello)
print fout.read()
On a machine I haven't
On Mon, 8 Aug 2005, Dave Korn wrote:
WJFFM:
Sorry, I was probably being to terse in what I included. To confirm, on
the newly updated machine, here's what I get:
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type help, copyright, credits or license
Original Message
From: Nick Burch
Sent: 08 August 2005 15:13
On Mon, 8 Aug 2005, Dave Korn wrote:
I reckon you probably got bitten by the recent sh/ash/bash transition
problems. You could post your cygcheck output as described at
http://cygwin.com/problems.html if you want us to
On Mon, 8 Aug 2005, Dave Korn wrote:
Not Found: sh
That'll be it. All system (...) calls are critically dependent on sh
existing and being runnable! Re-run setup and select 'Reinstall' for bash,
or manually run the postinstall script, or just cp /bin/bash.exe
/bin/sh.exe, then have another
Gerrit P. Haase wrote:
Do you mean the code compiled on the sane machine, where
the binary runs ok when compiled with the older binutils, is crashing
when simply copying the executable to another machine?
When copying the executable and dll, yes. That very same pair also
crashes on the
Stein Somers wrote:
Gerrit P. Haase wrote:
Do you mean the code compiled on the sane machine, where
the binary runs ok when compiled with the older binutils, is crashing
when simply copying the executable to another machine?
When copying the executable and dll, yes. That very same pair
After another fierce struggle with Cygwin Setup, it has downgraded the
cygwin package from 1.5.18-1 to 1.5.17-1. Bash also needed to be
downgraded, and sort and other tools are not on speaking terms with the
old cygwin either, but what's important is that, with the old
cygwin1.dll, the gcc
Stein Somers wrote:
Gerrit P. Haase wrote:
I have not tried to build it with gcc-3.3.3, could someone with this
version handy build an executable and send it to me, please?
Here's a set of 3: my 3.3 build (succeeding), my latest 3.4 build
(failing as yours), and the successful 3.4 build
On Wed, 3 Aug 2005, Stein Somers wrote:
Unfortunately, I was too eager to try the upgrade to note the version it
was upgraded from.
FYI, the information about all of your upgrades done via Cygwin setup
(including the version you upgraded from) can be obtained from
/var/log/setup.log.
I think
Igor Pechtchanski wrote:
FYI, the information about all of your upgrades done via Cygwin setup
(including the version you upgraded from) can be obtained from
/var/log/setup.log.
I actually checked this file on my machine (and all others changed
recently) and couldn't find anything relevant.
On 8/3/05, Igor Pechtchanski wrote:
On Wed, 3 Aug 2005, Stein Somers wrote:
Unfortunately, I was too eager to try the upgrade to note the version it
was upgraded from.
FYI, the information about all of your upgrades done via Cygwin setup
(including the version you upgraded from) can be
On Wed, 3 Aug 2005, Joshua Daniel Franklin wrote:
On 8/3/05, Igor Pechtchanski wrote:
On Wed, 3 Aug 2005, Stein Somers wrote:
Unfortunately, I was too eager to try the upgrade to note the version it
was upgraded from.
FYI, the information about all of your upgrades done via Cygwin
Stein Somers wrote:
In short, cygwin 1.5.17-1 good, 1.5.18-1 bad. As Gerrit wrote from the
start.
Just as a point of strange coincidence, cygwin 1.5.17-1 good, 1.5.18-1 bad
seems to be the case with the recent Python and Postgres problems reported
as well. Also both appear on the surface
On Aug 3 15:38, Jon A. Lambert wrote:
Stein Somers wrote:
In short, cygwin 1.5.17-1 good, 1.5.18-1 bad. As Gerrit wrote from the
start.
Just as a point of strange coincidence, cygwin 1.5.17-1 good, 1.5.18-1
bad seems to be the case with the recent Python and Postgres problems
Corinna Vinschen wrote:
http://cygwin.com/problems.html
I've already done gone and did that.
I'm happy on existing configuration.
I withdraw my casual observation.
--
J Lambert
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
101 - 200 of 310 matches
Mail list logo
