Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
7100 64-bit. Basically, bash just crashes on startup. I don't have
access to a Vista machine right now but it's worthwhile confirming on
it.
I don't have access to any of these (just XP, here), so I can't really
tell
On Jul 3 10:11, Vincent R. wrote:
Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
7100 64-bit. Basically, bash just crashes on startup. I don't have
access to a Vista machine right now but it's worthwhile confirming on
it.
I don't have access to any of these
Eric Blake wrote:
61020293 looks like an address in the dll range, probably cygwin1.dll. It
would be nice to know what function is dying, but doing that may require
rebuilding a bash image with debugging symbols. Did you by chance do any
rebasing? Maybe this is a case where I didn't use the
Edward Lam edward at sidefx.com writes:
61020293 looks like an address in the dll range, probably cygwin1.dll. It
would be nice to know what function is dying, but doing that may require
rebuilding a bash image with debugging symbols. Did you by chance do any
rebasing? Maybe this is a
On Fri, 3 Jul 2009 14:03:35 + (UTC), Eric Blake e...@byu.net wrote:
Edward Lam edward at sidefx.com writes:
61020293 looks like an address in the dll range, probably cygwin1.dll.
It
would be nice to know what function is dying, but doing that may
require
rebuilding a bash image
Vincent R. forumer at smartmobili.com writes:
is it the first time you compile readline with gcc-4 ?
Yes, plus readline 6.0 is a new upstream release.
--
Eric Blake
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Dave Korn dave.korn.cygwin at googlemail.com writes:
I'm wondering if the problem is not how I compiled bash, but how I compiled
readline. Dave, any pointers I should try or maybe a missed compiler flag
I
should have used to build libreadline7 with gcc4? I'm shooting in the
dark,
Eric Blake wrote:
Dave Korn dave.korn.cygwin at googlemail.com writes:
I'm wondering if the problem is not how I compiled bash, but how I compiled
readline. Dave, any pointers I should try or maybe a missed compiler flag
I
should have used to build libreadline7 with gcc4? I'm shooting
Eric Blake wrote:
I'm wondering if the problem is not how I compiled bash, but how I compiled
readline. Dave, any pointers I should try or maybe a missed compiler flag I
should have used to build libreadline7 with gcc4? I'm shooting in the dark,
since I can't seem to reproduce the
On Jul 2 06:42, Andy Koppe wrote:
2009/7/2 Christopher Faylor:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in the last
month. Every special case accommodation we make to allow MS-DOSisms
to work seamlessly
Christopher Faylor wrote:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in the last
month. Every special case accommodation we make to allow MS-DOSisms
to work seamlessly adds code to Cygwin and cause corresponding
On Thu, Jul 02, 2009 at 09:58:06AM +0200, Corinna Vinschen wrote:
On Jul 2 06:42, Andy Koppe wrote:
2009/7/2 Christopher Faylor:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in the last
month. ?Every special
On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
Christopher Faylor wrote:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in the last
month. Every special case accommodation we make to allow MS-DOSisms to
work
Christopher Faylor wrote:
On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
Christopher Faylor wrote:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in the last
month. Every special case accommodation we
On Thu, Jul 02, 2009 at 02:10:27PM -0400, Edward Lam wrote:
Christopher Faylor wrote:
On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
Christopher Faylor wrote:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in
Hi Eric,
I seem to no longer be able to install bash 3.2.49-22 in cygwin 1.7? I
even tried doing a fresh cygwin install, choosing explicitly to use bash
3.2.49-22 instead of 3.2.49-23. During the installation, I get an error
saying that cygreadline6.dll is missing. Any ideas?
I also tried
Hi Eric,
I got bash 3.2.49-22 running again in cygwin 1.7 after explicitly
installing libreadline6.
Ok, so I can confirm a problem with bash 3.2.49-23 on Windows 7 RC build
7100 64-bit. Basically, bash just crashes on startup. I don't have
access to a Vista machine right now but it's
Edward Lam wrote:
No, they just aren't as mean as we are. We like to make things
purposely slow because then people suffer.
I asked what I thought was a sensible question for someone who doesn't
know the internal workings of cygwin/mingw. It wasn't meant as a flame
bait.
Flame? Oh, my
On Thu, Jul 02, 2009 at 04:14:23PM -0600, Warren Young wrote:
Like in many online fora, it's best to try to maintain a thick skin
here, so as to be less easily upset.
It is more fun to translate attempts at humor or sarcasm as a
near-mortal wounds. This allows others to heroically step in to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please don't top-post, and trim your replies to just include relevant
text: http://cygwin.com/acronyms/#TOFU
According to Edward Lam on 7/2/2009 3:14 PM:
Hi Eric,
I got bash 3.2.49-22 running again in cygwin 1.7 after explicitly
installing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new release of bash, 3.2.49-23, has been uploaded for those testing
cygwin 1.7, replacing 3.2.49-22 as current.
NEWS:
=
This is a package refresh, built against cygwin 1.7. It closes a buffer
overflow exploit security hole that was reported to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Edward Lam on 7/1/2009 8:52 PM:
On Wed, July 1, 2009 22:17, Eric Blake wrote:
It also removes special
handling for DOS paths, since cygwin 1.7 is less accommodating to those
(use /cygdrive instead).
Can you clarify what this means
On Wed, July 1, 2009 22:17, Eric Blake wrote:
It also removes special
handling for DOS paths, since cygwin 1.7 is less accommodating to those
(use /cygdrive instead).
Can you clarify what this means exactly compared to say the latest bash
version in cigwin 1.5? Personally, I rely on using DOS
On Wed, Jul 01, 2009 at 09:03:39PM -0600, Eric Blake wrote:
If you have /cygdrive/c mounted as a text mount point, then
echo /cygdrive/c/file
continues to do text processing, but the alternate construct
echo c:\file
now behaves in a binary fashion (in 1.5, I had been special casing DOS
paths
2009/7/2 Christopher Faylor:
And for those who want to wail about this, take a look at the various
Why is Cygwin so slow threads that have been here in the last
month. Every special case accommodation we make to allow MS-DOSisms
to work seamlessly adds code to Cygwin and cause
25 matches
Mail list logo
