Re: ITA: gcc-mingw-* gcc-3 -mno-cygwin support packages; ITP: mingw-binutils/mingw-gcc-* cross compiler
On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote: Updated packages are available by pointing setup.exe here: http://cygutils.fruitbat.org/ITP/mingw-gcc/ Could you sign your setup.ini and post the GPG key (for setup -K)? = mingw-zlib-1.2.5-4-src.tar.bz2 = mingw-zlib-1.2.5-4.tar.bz2 = mingw-zlib-devel-1.2.5-4.tar.bz2 = mingw-zlib1-1.2.5-4.tar.bz2 The sharedlibdir variable in zlib.pc needs to be fixed. Yaakov
failing to clone a git repo via ssh
This repo clones fine in msysgit and on linux over ssh, but on cygwin this is what happens: $ git clone dbsrg...@git.shadowcat.co.uk:DBIx-Class.git dbic Cloning into dbic... Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. remote: Counting objects: 43957, done. remote: Compressing objects: 100% (16772/16772), done. fatal: The remote end hung up unexpectedly6 MiB | 384 KiB/s fatal: early EOFs: 89% (39122/43957), 5.64 MiB | 402 KiB/s fatal: index-pack failed The git:// URL works fine (git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git). Come to #dbix-class on irc.perl.org if you want me to add your ssh key added, or attach it here... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
I just realized this bug is replicatable without having ssh access to our repo, you just need the cygwin sshd enabled, and the guy with access to the gitosis went off somewhere anyway... Here are the steps: cd ~ mkdir tmp cd tmp git clone git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git dbic_git_url git clone `whoami`@localhost:tmp/dbic_git_url dbic_ssh On 1/23/2011 5:01 AM, Rafael Kitover wrote: This repo clones fine in msysgit and on linux over ssh, but on cygwin this is what happens: $ git clone dbsrg...@git.shadowcat.co.uk:DBIx-Class.git dbic Cloning into dbic... Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. remote: Counting objects: 43957, done. remote: Compressing objects: 100% (16772/16772), done. fatal: The remote end hung up unexpectedly6 MiB | 384 KiB/s fatal: early EOFs: 89% (39122/43957), 5.64 MiB | 402 KiB/s fatal: index-pack failed The git:// URL works fine (git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git). Come to #dbix-class on irc.perl.org if you want me to add your ssh key added, or attach it here... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
remapping error with python fork
Hi, On a Win 7 64Bit System I use CYGWIN_NT-6.1-WOW64 1.7.7(0.230/5/3). Working with python I get errors reporting that cygwin was not able to remap zlib or time DLL. The error occures only from time to time on one script I develop when it calls fork. In response I invoked rebaseall. Right now it gives me the following output: $ rebaseall /usr/lib/cygicudata.dll: skipped because nonexistent /usr/lib/cygicui18n.dll: skipped because nonexistent /usr/lib/cygicuio.dll: skipped because nonexistent /usr/lib/cygicule.dll: skipped because nonexistent /usr/lib/cygiculx.dll: skipped because nonexistent /usr/lib/cygicutu.dll: skipped because nonexistent /usr/lib/cygicuuc.dll: skipped because nonexistent The error keeps occuring though. Additionally, I find myself stuck on the way to install pysnmp, a python snmp library. Everytime I invoke easy_install pysnmp the error I mentioned appears: $ easy_install pysnmp Searching for pysnmp Best match: pysnmp 4.1.15a Processing pysnmp-4.1.15a-py2.6.egg [...] Downloading http://www.pycrypto.org/files/pycrypto-2.3.tar.gz Processing pycrypto-2.3.tar.gz Running pycrypto-2.3/setup.py -q bdist_egg --dist-dir /tmp/easy_install-XxXguJ/pycrypto-2.3/egg-dist-tmp-qSdDwR warning: GMP library not found; Not building Crypto.PublicKey._fastmath. 1 [main] python2.6 608 C:\prog\cygwin\bin\python2.6.exe: *** fatal error - unable to remap \\?\C:\prog\cygwin\lib\python2.6\lib-dynload\time.dll to same address as parent: 0x39 != 0x41 1 [main] python2.6 608 C:\prog\cygwin\bin\python2.6.exe: *** fatal error - unable to remap \\?\C:\prog\cygwin\lib\python2.6\lib-dynload\time.dll to same address as parent: 0x39 != 0x41 Stack trace:n] python2.6 3536 fork: child 608 - died waiting for dll loading, errno 11 Frame Function Args 00285518 6102749B (00285518, , , ) 00285808 6102749B (61177B80, 8000, , 61179977) 00286838 61004AFB (611A136C, 6123A734, 0039, 0041) End of stack trace 1 [main] python2.6 3536 fork: child 608 - died waiting for dll loading, errno 11 error: Setup script exited with error: Resource temporarily unavailable Please let me know if you have any suggestions on how to solve this issue. Thanks, Johannes Müller -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invoking GUI programs over SSH
On 01/22/2011 04:01 PM, Csaba Raduly wrote: On Sat, Jan 22, 2011 at 3:21 PM, Andrew DeFaria wrote: Software that *requires* CRLF should be taken out an shot! You mean like every FTP server and client ? : Do FTP servers and clients *require* CRLF's or do they simply deal with and handle them? Are you saying that if I have a file that only has LF's in it then FTP will refuse to work? -- Andrew DeFaria http://defaria.com Prediction is very difficult, especially about the future. - Niels Bohr -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
On 01/23/2011 06:21 AM, Rafael Kitover wrote: I just realized this bug is replicatable without having ssh access to our repo, you just need the cygwin sshd enabled, and the guy with access to the gitosis went off somewhere anyway... Here are the steps: cd ~ mkdir tmp cd tmp git clone git://git.shadowcat.co.uk/dbsrgits/DBIx-Class.git dbic_git_url git clone `whoami`@localhost:tmp/dbic_git_url dbic_ssh Sadly, the early EOFs problem is an identified but unfixed issue: http://cygwin.com/ml/cygwin/2010-07/msg00413.html http://cygwin.com/ml/cygwin/2010-10/msg00044.html Since my last report in that thread, I did try a few other configurations: * msysGit with msysGit's ssh * msysGit with Cygwin's ssh * Cygwin's git with msysGit's ssh All of these combinations avoided the early EOFs problem no matter how many times I repeated my testing. As cgf said, this does appear to be a problem in Cygwin's pipe code, but it's very strange that it only seems to be triggered with Cygwin's git + Cygwin's ssh. My guess is that there is some kind of race condition in the pipe setup code when both ends of the pipe are Cygwin processes, but I'm admittedly unfamiliar with Cygwin's pipe code. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
- Original Message - From: Jeremy Bopp jer...@bopp.net All of these combinations avoided the early EOFs problem no matter how many times I repeated my testing. As cgf said, this does appear to be a problem in Cygwin's pipe code, but it's very strange that it only seems to be triggered with Cygwin's git + Cygwin's ssh. My guess is that there is some kind of race condition in the pipe setup code when both ends of the pipe are Cygwin processes, but I'm admittedly unfamiliar with Cygwin's pipe code. Possibly the same issue which still plagues rsync under cygwin? Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: failing to clone a git repo via ssh
On 01/23/2011 01:37 PM, Steven Hartland wrote: - Original Message - From: Jeremy Bopp jer...@bopp.net All of these combinations avoided the early EOFs problem no matter how many times I repeated my testing. As cgf said, this does appear to be a problem in Cygwin's pipe code, but it's very strange that it only seems to be triggered with Cygwin's git + Cygwin's ssh. My guess is that there is some kind of race condition in the pipe setup code when both ends of the pipe are Cygwin processes, but I'm admittedly unfamiliar with Cygwin's pipe code. Possibly the same issue which still plagues rsync under cygwin? I've thought the same thing myself, but I don't have any test cases for that and haven't experienced the problem directly. As I recall, the rsync case manifests as a hang which seems a bit different than this case of unexpected EOFs. It's possible that it could be rsync's reaction to the unexpected EOF could mask it as a hang, I suppose. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invoking GUI programs over SSH
On Sun, Jan 23, 2011 at 2:43 PM, Andrew DeFaria wrote: On 01/22/2011 04:01 PM, Csaba Raduly wrote: On Sat, Jan 22, 2011 at 3:21 PM, Andrew DeFaria wrote: Software that *requires* CRLF should be taken out an shot! You mean like every FTP server and client ? : Do FTP servers and clients *require* CRLF's or do they simply deal with and handle them? Are you saying that if I have a file that only has LF's in it then FTP will refuse to work? The protocol itself requires CRLF line separators, so clients and servers should too. POP, IMAP and SMTP also require CRLF. I hope we can keep those :) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
windows paths in shebang lines
When a script's shebang line has a windows path, rather than a cygwin path, it does not work: rkitover@eeebox ~ $ head -1 /cygdrive/c/Perl64/site/bin/ack #!C:\Perl64\bin\perl rkitover@eeebox ~ $ /cygdrive/c/Perl64/site/bin/ack --version Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory On msys (msysGit) this works correctly: rkitover@EEEBOX ~ $ /c/Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe Copyright 2005-2010 Andy Lester. This program is free software. You may modify or distribute it under the terms of the Artistic License v2.0. Any chance this could be fixed? This would be a very nice feature for users of Strawberry Perl and similar. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: windows paths in shebang lines
On 01/23/2011 03:47 PM, Rafael Kitover wrote: When a script's shebang line has a windows path, rather than a cygwin path, it does not work: rkitover@eeebox ~ $ head -1 /cygdrive/c/Perl64/site/bin/ack #!C:\Perl64\bin\perl rkitover@eeebox ~ $ /cygdrive/c/Perl64/site/bin/ack --version Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory On msys (msysGit) this works correctly: rkitover@EEEBOX ~ $ /c/Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe Copyright 2005-2010 Andy Lester. This program is free software. You may modify or distribute it under the terms of the Artistic License v2.0. Any chance this could be fixed? This would be a very nice feature for users of Strawberry Perl and similar. The problem is not that you're using a Windows path instead of a Cygwin path in the shebang line; although, that is not officially supported under Cygwin. Rather, the problem is that the version of Perl being run as a result of that shebang line does not understand Cygwin paths. That's why you see this error: Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory That's the Perl interpreter telling you that it doesn't understand the path that was given to it for the ack script, so Perl is running at this point which means that the shebang line is understood correctly. You should probably go read about how shebang lines work in general, but the short and sweet is that the shebang line is the first part of a command line to be run where the last part is the command line used to run the file that contains the shebang line itself. IOW, the command line used in your first example is ultimately: C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version You have 3 potential solutions to your problem: 1) Run Perl explicitly with the Windows path to the script as an argument: /cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack 2) Change into the C: drive and use a relative path to the ack script when you run it: cd /cygdrive/c Perl64/site/bin/ack 3) Change your cygdrive mount location to / so that the path to the ack script will be /c/Perl64/site/bin/ack under Cygwin. Option 3 is the real hack. I think it should work because it appears in your successful example that the Perl you want to use is able to translate paths such as /c/path/to/something to C:/path/to/something internally. By adjusting the cygdrive mount location to /, you will cause Cygwin to send a compatible path to Perl when you run the script as /c/Perl64/site/bin/ack. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: windows paths in shebang lines
On 01/23/2011 05:59 PM, Jeremy Bopp wrote: On 01/23/2011 03:47 PM, Rafael Kitover wrote: When a script's shebang line has a windows path, rather than a cygwin path, it does not work: rkitover@eeebox ~ $ head -1 /cygdrive/c/Perl64/site/bin/ack #!C:\Perl64\bin\perl rkitover@eeebox ~ $ /cygdrive/c/Perl64/site/bin/ack --version Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory On msys (msysGit) this works correctly: rkitover@EEEBOX ~ $ /c/Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe Copyright 2005-2010 Andy Lester. This program is free software. You may modify or distribute it under the terms of the Artistic License v2.0. Any chance this could be fixed? This would be a very nice feature for users of Strawberry Perl and similar. The problem is not that you're using a Windows path instead of a Cygwin path in the shebang line; although, that is not officially supported under Cygwin. Rather, the problem is that the version of Perl being run as a result of that shebang line does not understand Cygwin paths. That's why you see this error: Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory That's the Perl interpreter telling you that it doesn't understand the path that was given to it for the ack script, so Perl is running at this point which means that the shebang line is understood correctly. You should probably go read about how shebang lines work in general, but the short and sweet is that the shebang line is the first part of a command line to be run where the last part is the command line used to run the file that contains the shebang line itself. IOW, the command line used in your first example is ultimately: C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version You have 3 potential solutions to your problem: 1) Run Perl explicitly with the Windows path to the script as an argument: /cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack 2) Change into the C: drive and use a relative path to the ack script when you run it: cd /cygdrive/c Perl64/site/bin/ack 3) Change your cygdrive mount location to / so that the path to the ack script will be /c/Perl64/site/bin/ack under Cygwin. Option 3 is the real hack. I think it should work because it appears in your successful example that the Perl you want to use is able to translate paths such as /c/path/to/something to C:/path/to/something internally. By adjusting the cygdrive mount location to /, you will cause Cygwin to send a compatible path to Perl when you run the script as /c/Perl64/site/bin/ack. -Jeremy My question would be: Why are you running a C:\Perl64\bin\perl.exe instead of just running /usr/bin/perl (AKA C:/Cygwin/bin/perl.exe)? IOW why are you not running Cygwin's Perl. My guess is that C:\Perl64\bin\perl.exe is some ActiveState based Perl and you'll only run into problems using that with a Cygwin frame of mine. Just run Cygwin's Perl instead! -- Andrew DeFaria http://defaria.com Friends may come and go, but enemies accumulate. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: windows paths in shebang lines
On 1/23/2011 5:59 PM, Jeremy Bopp wrote: On 01/23/2011 03:47 PM, Rafael Kitover wrote: When a script's shebang line has a windows path, rather than a cygwin path, it does not work: rkitover@eeebox ~ $ head -1 /cygdrive/c/Perl64/site/bin/ack #!C:\Perl64\bin\perl rkitover@eeebox ~ $ /cygdrive/c/Perl64/site/bin/ack --version Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory On msys (msysGit) this works correctly: rkitover@EEEBOX ~ $ /c/Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe Copyright 2005-2010 Andy Lester. This program is free software. You may modify or distribute it under the terms of the Artistic License v2.0. Any chance this could be fixed? This would be a very nice feature for users of Strawberry Perl and similar. The problem is not that you're using a Windows path instead of a Cygwin path in the shebang line; although, that is not officially supported under Cygwin. Rather, the problem is that the version of Perl being run as a result of that shebang line does not understand Cygwin paths. That's why you see this error: Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory That's the Perl interpreter telling you that it doesn't understand the path that was given to it for the ack script, so Perl is running at this point which means that the shebang line is understood correctly. You should probably go read about how shebang lines work in general, but the short and sweet is that the shebang line is the first part of a command line to be run where the last part is the command line used to run the file that contains the shebang line itself. IOW, the command line used in your first example is ultimately: C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version Ahh yes, I wasn't thinking about this clearly, thank you for the explanation :) You have 3 potential solutions to your problem: 1) Run Perl explicitly with the Windows path to the script as an argument: /cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack 2) Change into the C: drive and use a relative path to the ack script when you run it: cd /cygdrive/c Perl64/site/bin/ack 3) Change your cygdrive mount location to / so that the path to the ack script will be /c/Perl64/site/bin/ack under Cygwin. Option 3 is the real hack. I think it should work because it appears in your successful example that the Perl you want to use is able to translate paths such as /c/path/to/something to C:/path/to/something internally. By adjusting the cygdrive mount location to /, you will cause Cygwin to send a compatible path to Perl when you run the script as /c/Perl64/site/bin/ack. -Jeremy Unfortunately, that's not enough to get it to work: $ /c/Perl64/site/bin/ack --version Can't open perl script /c/Perl64/site/bin/ack: No such file or directory $ /c/Perl64/bin/perl /c/Perl64/site/bin/ack --version Can't open perl script /c/Perl64/site/bin/ack: No such file or directory $ /c/Perl64/bin/perl /Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe ... msys seems to do something special for this to work correctly, it also seems to translate its paths to windows paths when running windows executables automatically, a very nice feature. For this to work in cygwin I'd have to do something like mount c: as /, which I'm guessing would break absolutely everything :) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: windows paths in shebang lines
On 1/23/2011 6:12 PM, Andrew DeFaria wrote: On 01/23/2011 05:59 PM, Jeremy Bopp wrote: On 01/23/2011 03:47 PM, Rafael Kitover wrote: When a script's shebang line has a windows path, rather than a cygwin path, it does not work: rkitover@eeebox ~ $ head -1 /cygdrive/c/Perl64/site/bin/ack #!C:\Perl64\bin\perl rkitover@eeebox ~ $ /cygdrive/c/Perl64/site/bin/ack --version Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory On msys (msysGit) this works correctly: rkitover@EEEBOX ~ $ /c/Perl64/site/bin/ack --version ack 1.94 Running under Perl 5.12.2 at C:\Perl64\bin\perl.exe Copyright 2005-2010 Andy Lester. This program is free software. You may modify or distribute it under the terms of the Artistic License v2.0. Any chance this could be fixed? This would be a very nice feature for users of Strawberry Perl and similar. The problem is not that you're using a Windows path instead of a Cygwin path in the shebang line; although, that is not officially supported under Cygwin. Rather, the problem is that the version of Perl being run as a result of that shebang line does not understand Cygwin paths. That's why you see this error: Can't open perl script /cygdrive/c/Perl64/site/bin/ack: No such file or directory That's the Perl interpreter telling you that it doesn't understand the path that was given to it for the ack script, so Perl is running at this point which means that the shebang line is understood correctly. You should probably go read about how shebang lines work in general, but the short and sweet is that the shebang line is the first part of a command line to be run where the last part is the command line used to run the file that contains the shebang line itself. IOW, the command line used in your first example is ultimately: C:\Perl64\bin\perl /cygdrive/c/Perl64/site/bin/ack --version You have 3 potential solutions to your problem: 1) Run Perl explicitly with the Windows path to the script as an argument: /cygdrive/c/Perl64/bin/perl C:/Perl64/site/bin/ack 2) Change into the C: drive and use a relative path to the ack script when you run it: cd /cygdrive/c Perl64/site/bin/ack 3) Change your cygdrive mount location to / so that the path to the ack script will be /c/Perl64/site/bin/ack under Cygwin. Option 3 is the real hack. I think it should work because it appears in your successful example that the Perl you want to use is able to translate paths such as /c/path/to/something to C:/path/to/something internally. By adjusting the cygdrive mount location to /, you will cause Cygwin to send a compatible path to Perl when you run the script as /c/Perl64/site/bin/ack. -Jeremy My question would be: Why are you running a C:\Perl64\bin\perl.exe instead of just running /usr/bin/perl (AKA C:/Cygwin/bin/perl.exe)? IOW why are you not running Cygwin's Perl. My guess is that C:\Perl64\bin\perl.exe is some ActiveState based Perl and you'll only run into problems using that with a Cygwin frame of mine. Just run Cygwin's Perl instead! But I do! :) I'm a CPAN developer, I love all perls and run as many of them as possible :) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: max memory
Christopher Faylor wrote: Cygwin only uses as much memory as the OS gives it. It can't use a full 2048MB for the heap. Using the /LARGEADDRESSAWARE flag would allow cygwin to access up to a full 4GB of memory under Win7-64. Wouldn't that give enough to Cygwin to allow it to give more to the heap? There's several 32-bit progs that should have been able to use over 2GB, with even XP being configurable to run with 3GB of user/1GB system space, but this was not very usable due to XP being hobbled to ignore extended memory (available on XEON processors many years back that allowed up to 64G on 32-bit machines). With 64-bit OS's User programs can easily be given more than 2G of addr space, but to allow this programs have to be linked with the largeaddressaware flag. Then 32-bit cygwin could theoretically use up to 4GB of memory. If that was the case, cygwin should be able to allocate more memory for user space (search firefox's bugdb for that flag for notes on its progress toward getting that switch enabled -- apparently ready but not yet enabled in shipping versions). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
