Re: [RFU 1.5] task-1.8.5-1
On Dec 11 01:11, Federico Hernandez wrote: Packages are no longer being accepted for Cygwin 1.5. So I repackage for 1.7 and do a new RFU then, correct? You should also build the package for and under 1.7 using gcc-4, not just repackage the 1.5 builds. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] smartmontools-5.39-1
On Dec 10 22:24, Christian Franke wrote: New upstream release wget \ http://franke.dvrdns.org/cygwin/release-2/smartmontools/smartmontools-5.39-1.tar.bz2 \ http://franke.dvrdns.org/cygwin/release-2/smartmontools/smartmontools-5.39-1-src.tar.bz2 \ http://franke.dvrdns.org/cygwin/release-2/smartmontools/setup.hint Uploaded. I just removed cygwin from the requires line. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: suite3270 3.3.4p7-2
On Dec 10 21:06, Peter A. Castro wrote: Hi! As per Corinna's request, all suite3270 packages have been recompiled for Cygwin 1.7 with all directory hierarchy retargeted for /usr instead of /usr/X11R6. Please upload: Source Install packages: wget \ http://www.fruitbat.org/Cygwin/suite3270/suite3270-3.3.4p7-2.tar.bz2 \ http://www.fruitbat.org/Cygwin/suite3270/suite3270-3.3.4p7-2-src.tar.bz2 \ http://www.fruitbat.org/Cygwin/suite3270/c3270-3.3.4p7-2.tar.bz2 \ http://www.fruitbat.org/Cygwin/suite3270/pr3287-3.3.4p7-2.tar.bz2 \ http://www.fruitbat.org/Cygwin/suite3270/s3270-3.3.4p7-2.tar.bz2 \ http://www.fruitbat.org/Cygwin/suite3270/tcl3270-3.3.4p7-2.tar.bz2 \ http://www.fruitbat.org/Cygwin/suite3270/x3270-3.3.4p7-2.tar.bz2 Updated setup.hint files: wget \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.c3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.pr3287 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.s3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.tcl3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.x3270 Thank you! Uploaded. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: suite3270 3.3.4p7-2
On Dec 11 10:34, Corinna Vinschen wrote: On Dec 10 21:06, Peter A. Castro wrote: Updated setup.hint files: wget \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.suite3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.c3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.pr3287 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.s3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.tcl3270 \ http://www.fruitbat.org/Cygwin/suite3270/setup.hint.x3270 Thank you! Uploaded. Forgot to mention: I removed cygwin from all requires lines. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 1.7 installation failed (on network drive?)
Corinna Vinschen wrote: Thomas, On Dec 7 17:09, Thomas Wolff wrote: I've tested the network installation with last Saturday's update of setup-1.7.exe and unfortunately, the problem remains. However, I can add a screen log after calling setup from mintty for the case that setup cannot even store its log anywhere (attached). Don't know if that helps. Apparently setup-1-7.exe cannot create directories (including the top package directory) on that network NFTS drive, although all other tools can easily create them. Despite cgf's point this should not delay the 1.7.1 release, may I suggest once more (and I'm not adding this to the 1.7.1 release date thread) that while the release is being delayed anyway due to other discussions, we might as well try to resolve this. Personally, I can do with a workaround; I'm just trying to help avoid trouble with other users complaining after the release... Thomas I just had another look into this and unfortunately I still can't reproduce it. What I see in your log output is the fact that ... hang on ... io_stream_cygfile: fopen(/etc/setup/timestamp) failed 13 Permission denied io_stream_cygfile: fopen(/var/run/utmp) failed 13 Permission denied io_stream_cygfile: fopen(/etc/setup/alternatives.lst.gz) failed 13 Permission denied [etc] So the fopen calls fail. fopen in setup is actually a call to nt_wfopen in filemanip.cc. If you could take a look, it's not a very complicated function. The general idea is to call NtCreateFile with FILE_OPEN_FOR_BACKUP_INTENT rights to allow an admin to install without permission trouble. As you can see, the error handling (lines 466ff) is somewhat oversimplified. You get a Permission denied as a fallback error if none of the path-related errors is triggered. Unfortunately we don't know the exact status code returned by NtCreateFile and I have no real idea what the problem might be. I have traced the status values returned by NtCreateFile (with printf actually), see the screen logs attached. I pasted in the popup error messages where they occurred. There is a bunch of the following NtCreateFile problems in the log: #define STATUS_ACCESS_DENIED ((NTSTATUS)0xC022L) #define STATUS_OBJECT_NAME_INVALID ((NTSTATUS)0xC033L) #define STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC034L) #define STATUS_OBJECT_PATH_NOT_FOUND ((NTSTATUS)0xC03AL) #define STATUS_OBJECT_PATH_SYNTAX_BAD ((NTSTATUS)0xC03BL) However, before the fatal error occurs, it's just STATUS_ACCESS_DENIED in both cases. What we need is this: Build a debug version of setup (you need gcc-3 for that since the -mno-cygwin option is still used), start it under GDB, and set a breakpoint to filemanip.cc:468. GDB will break there if an error gets triggered. Examine what status codes are returned. See /usr/include/w32api/ddk/ntstatus.h what status code that is. I also ran it with gdb and could just see the same status code that' also in my trace log; don't know if there's any other gdb-retrieved information you'd like to see. That might give us some clue. The only vague idea what you could try else is to remove the FILE_OPEN_REPARSE_POINT flag from the NtCreateFile call and see if it works without that. That makes no difference, I tried both versions. The flag is only used in filemanip.cc anyway while the problem occurs in mkdir.cc. Hope this helps a little bit, maybe at least for coming up with further debug instructions. Thomas Starting cygwin install, version 2.662 filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/last-action) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or directory filemanip:NtCreateFile - C03B filemanip:NtCreateFile - C03A io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory Current Directory: h:\ User has NO backup/restore rights Could not open Service control manager
RFU: sqlite 3.6.21-1
New upstream release: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21*' -r \ http://etr-usa.com/cygwin/sqlite3/ This is the first version packaged explicitly for 1.7. Previous 3.6.2 was copied over from 1.5 repo.
RFU: ctags 5.8-1
New upstream release: wget -e robots=off --cut-dirs=2 -np -nH -A'*5.8-1*' -r \ http://etr-usa.com/cygwin/ctags/ setup.hint unchanged. This is the first version packaged explicitly for 1.7. Previous 5.7 was copied over from 1.5 repo.
RFU: doxygen 1.6.1-1
New upstream release: wget -e robots=off --cut-dirs=2 -np -nH -A'*1.6.1-1*' -r \ http://etr-usa.com/cygwin/doxygen/ setup.hint unchanged. This is the first version packaged explicitly for 1.7. Previous 1.5.5 was copied over from 1.5 repo.
Re: 1.7 installation failed (on network drive?)
Thomas Wolff wrote: Selected local directory: H:\cygwin17p1 mkdir:NtCreateFile - C022 mbox note: Couldn't create directory H:\cygwin17p1, sorry. (Is drive full or read-only?) So that's coming from here: status = NtCreateFile (dir, STANDARD_RIGHTS_ALL | FILE_LIST_DIRECTORY, attr, io, NULL, FILE_ATTRIBUTE_DIRECTORY, FILE_SHARE_VALID_FLAGS, FILE_CREATE, FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_OPEN_FOR_BACKUP_INTENT, NULL, 0); Interesting. Does it possibly succeed if you remove the FILE_OPEN_FOR_BACKUP_INTENT flag? cheers, DaveK
Newbie: idle doesn't run
Hi, Below are the traces for checkx and idle: $ checkx --debug=2 checkx.exe DEBUG: opt_location: 0 checkx.exe DEBUG: opt_loglevel: 8 checkx.exe DEBUG: opt_nogui : 0 checkx.exe DEBUG: opt_notty : 0 checkx.exe DEBUG: opt_timeout : 0.50 checkx.exe DEBUG: (adjust_path) path is : /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:.:/usr/bin:/cygdrive/c/oracle/ora81/bin:/cygdrive/c/Archivos de programa/Oracle/jre/1.1.7/bin:/cygdrive/c/WINDOWS/SYSTEM32:/cygdrive/c/WINDOWS:/cygdrive/c/Serena/CHANGE~1/DIMENS~1/9.1/PROG:/cygdrive/c/sybase/OLEDB:/cygdrive/c/sybase/ODBC:/cygdrive/c/sybase/ASEP_Win32:/cygdrive/c/sybase/OCS-12_5/dll:/cygdrive/c/sybase/OCS-12_5/lib3p:/cygdrive/c/sybase/OCS-12_5/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/orawin95/Bin:/cygdrive/c/Archivos de programa/Java/jdk1.6.0_02/bin:/cygdrive/c/Archivos de programa/QuickTime/QTSystem/:/cygdrive/c/Archivos de programa/Windows Imaging/:/cygdrive/c/Archivos de programa/Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Archivos de programa/Microsoft Visual Studio/Common/Tools/WinNT:/cygdrive/c/Archivos de programa/Microsoft Visual Studio/Common/MSDev98/Bin:/cygdrive/c/Archivos de programa/Microsoft Visual Studio/Common/Tools:/cygdrive/c/Archivos de programa/Microsoft Visual Studio/VC98/bin:/cygdrive/c/ORAWIN95/BIN:/usr/bin:/usr/bin:/usr/bin:/usr/share/vim/vim72:.:/usr/X11R6/bin:/usr/bin checkx.exe DEBUG: (find_X11_lib) DLL is /usr/bin/cygX11-6.dll checkx.exe DEBUG: (dlopen_X11_lib) /usr/bin/cygX11-6.dll dlopen'ed successfully. checkx.exe DEBUG: (load_X11_symbols) symbol XOpenDisplay loaded ok checkx.exe DEBUG: (load_X11_symbols) symbol XCloseDisplay loaded ok checkx.exe DEBUG: (try_with_timeout) Using delay of 0 secs, 5 nanosecs ( 0.50) checkx.exe DEBUG: (try_with_timeout) xserver search was a success! checkx.exe Info: X display '127.0.0.1:0.0' successfully opened checkx.exe DEBUG: returning with status 0 checkx.exe Info: Exiting with status 0 jlfd...@jlfdiazwxp ~ $ idle 4 [main] python 2500 C:\cygwin\bin\python.exe: *** fatal error - unable to remap C:\cygwin\bin\tk84.dll to same address as parent(0x1876) != 0x18C5 9 [main] python 3876 fork: child 2500 - died waiting for dll loading, errno 11 Traceback (most recent call last): File /usr/bin/idle, line 5, in module main() File /usr/lib/python2.5/idlelib/PyShell.py, line 1404, in main shell = flist.open_shell() File /usr/lib/python2.5/idlelib/PyShell.py, line 277, in open_shell if not self.pyshell.begin(): File /usr/lib/python2.5/idlelib/PyShell.py, line 983, in begin client = self.interp.start_subprocess() File /usr/lib/python2.5/idlelib/PyShell.py, line 374, in start_subprocess self.spawn_subprocess() File /usr/lib/python2.5/idlelib/PyShell.py, line 350, in spawn_subprocess self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args) File /usr/lib/python2.5/os.py, line 562, in spawnv return _spawnvef(mode, file, args, None, execv) File /usr/lib/python2.5/os.py, line 530, in _spawnvef pid = fork() OSError: [Errno 11] Resource temporarily unavailable Thanks for your help, Jose Luis -- View this message in context: http://old.nabble.com/Newbie%3A-idle-doesn%27t-run-tp26741790p26741790.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: openbox-3.4.7.2-10, New: obconf-2.0.3-10
Yaakov (Cygwin/X) wrote... The following package has been updated for Cygwin 1.7: *** openbox-3.4.7.2-10 *** obconf-2.0.3-10 (NEW) This is not accessible through the new setup-1.7.exe. I can see openbox, but the version there is is 0.99.1-4. I am using mirrors.xmission.com. Is there a different way of getting these? thanks, josé -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [1.7] ctypes / geos / python / django
Yaakov (Cygwin/X) a écrit : On 10/12/2009 14:57, kiorky wrote: Oh, I see what you mean now. There was a bug in the libc.a in previous releases that should have been fixed in cygwin 1.7.0-68. What does dlltool -I /usr/lib/libc.a return? $ dlltool -I /usr/lib/libc.a cygwin1.dll -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature
Re: Cygwin 1.5.25, vim 7.2-3: Command 'cw' misbehaves on a block of contiguous white-spaces
On Dec 10 19:17, Avijit Ghosh wrote: VIM seems to be behaving improperly executing the 'cw' command when the cursor is positioned on a block of contiguous white-space characters. It is changing *only* the character it is positioned on (instead of changing up to the last white-space in the block). Consider the following example text (please read using fixed-width font): alpha beta ^ Cursor here If I type 'cwESC', I get: alpha beta I expect, based on using Win32 native VIM 7.2, Cygwin VIM 6.x, and other VIM/vi on Unix platforms -- and also on behavior or 'dw' or just 'w' on *this* version of VIM: alphabeta That is, I expect 'cw' to be equivalent in general to 'dwi', and 'cwESC' to be equivalent to 'dw' --- this is not the case any more, it seems. Works exactly as you expect it for me. I guess you have to blame one of your vim startup files like ~/.vimrc. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
[ANNOUNCEMENT] Updated: smartmontools-5.39-1
Version 5.39-1 of smartmontools has been uploaded. http://smartmontools.sourceforge.net/ Changes include: - Support for USB devices with Cypress, JMicron and Sunplus USB bridges - USB device type autodetection for some devices, see http://sourceforge.net/apps/trac/smartmontools/wiki/Supported_USB-Devices - smartctl option '-l xerror' to print ATA SMART Extended Comprehensive Error Log - smartctl option '-l xselftest' to print ATA SMART Extended Self-test Log - smartctl option '-l sataphy' to print SATA Phy Event Counters - smartctl option '-l sasphy' to print SAS device phy information - smartctl options '-l gplog,...' and '-l smartlog,...' to print any log page - smartctl option '-x' to print all extended info if available (The above require IOCTL_ATA_PASS_THROUGH in driver or 48-bit pass-through support in USB bridge) - smartctl prints SCSI load/unload cycle counts - Improve display of huge raw values of some SMART attributes - Option '-v ID,RAW_FORMAT,ATTR_NAME' to add new vendor specific attributes - Support for SSD drives using 64-bit raw attributes - Many additions to drive database - New simplified syntax for drive database - Drive database read from file (/usr/share/smartmontools/drivedb.h, /etc/smart_drivedb.h) - smartd can now handle attributes 197 and 198 with increasing raw values - smartd logs changes of self-test execution status - smartd directive '-n powermode,N' to limit the number of skipped checks - smartd flag '!' for '-r' and '-R' directives to log changes as critical - smartd supports scheduled Selective Self-Tests - Self-tests scheduled during system downtime or disk standby are run after next startup - smartd stores internal state until next startup (/var/lib/smartmontools/smartd.MODEL-SERIAL.ata.state) - smartd option '-A PREFIX' to log attributes at each check cycle For a full list of changes see NEWS and CHANGELOG in /usr/share/doc/smartmontools Please read the Windows and Cygwin sections in the files INSTALL and WARNINGS. For open issues see http://sourceforge.net/apps/trac/smartmontools/report/1 Description: Smartmontools contains utility programs (smartctl, smartd) to control/monitor storage systems using the Self-Monitoring, Analysis and Reporting Technology System (S.M.A.R.T.) built into most modern ATA and SCSI disks. In many cases, these utilities will provide advanced warning of disk degradation and failure. Smartctl is a command line utility designed to perform tasks such as printing the SMART self-test and error logs, enabling and disabling SMART automatic testing, and initiating device self-tests. Smartd is a daemon that monitors the drives every 30 minutes (configurable), logs SMART errors and changes of SMART Attributes via the syslog interface. Smartd can also be configured to schedule self-tests and send email warnings or run other scripts if problems are detected. On Cygwin, smartd can be run as a windows service via cygrunsrv. Christian Franke -- To update your installation, click on the Install or update now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin at cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Is 1.7 ready?/Installation Issues
On 12/11/2009 1:06 AM, Charles Wilson wrote: for f in /etc/postinstall/*.sh ; do /bin/bash -c $f mv $f $f.done done I think you need to omit '-c' because some postinstall scripts are not executable. Ken -- 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: Unable to install MingW gcc C C++ libraries
On 12/10/2009 7:18 PM, Chip Panarchy wrote: Sorry about that, did a half-thoughtout find/replace of my log before sending it out here. There is no N:\, everything is on the C:\. Once again: http://cygwin.com/acronyms/#TOFU http://cygwin.com/acronyms/#PCYMTNQREAIYR Take a look at the following thread and see if it helps: http://cygwin.com/ml/cygwin/2009-12/threads.html#00385 Ken -- 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
Cygwin 1.5.25, vim 7.2-3: [More Info] Command 'cw' misbehaves on a block of contiguous white-spaces
[Sorry I'm re-posting outside the thread as I don't know how to follow up on the mailing list when I'm not subscribed to it. Would be grateful if anyone can tell me how.] Additional information on the problem below -- I don't have any .vimrc, .gvimrc. .exrc or anything like that in my home directory. -- I've also tried running 'vim -u NONE' -- and I face the same problem. (I've seen a reply from Corinna Vinschen suggesting that there may be an issue with '.vimrc' -- so I cross checked.) -- Avijit On Dec 10 19:17, Avijit Ghosh wrote: VIM seems to be behaving improperly executing the 'cw' command when the cursor is positioned on a block of contiguous white-space characters. It is changing *only* the character it is positioned on (instead of changing up to the last white-space in the block). Consider the following example text (please read using fixed-width font): alpha beta ^ Cursor here If I type 'cwESC', I get: alpha beta I expect, based on using Win32 native VIM 7.2, Cygwin VIM 6.x, and other VIM/vi on Unix platforms -- and also on behavior or 'dw' or just 'w' on *this* version of VIM: alphabeta That is, I expect 'cw' to be equivalent in general to 'dwi', and 'cwESC' to be equivalent to 'dw' --- this is not the case any more, it seems. cygcheck.out Description: Binary data -- 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
Cygwin 1.5.25, vim 7.2-3: [Even more Info] 'cw' and white-space
Additional info: Looking up 'help cw' tells me that the behavior I am seeing should happen if the 'w' flag is set in 'cpoptions'. However, I checked my cpoptions (with 'set cpoptions?') -- and found that it is 'aABceFs' -- i.e. no 'w'. Problem still there. [Sorry I'm re-posting outside the thread as I don't know how to follow up on the mailing list when I'm not subscribed to it. Would be grateful if anyone can tell me how.] Additional information on the problem below -- I don't have any .vimrc, .gvimrc. .exrc or anything like that in my home directory. -- I've also tried running 'vim -u NONE' -- and I face the same problem. (I've seen a reply from Corinna Vinschen suggesting that there may be an issue with '.vimrc' -- so I cross checked.) -- Avijit On Dec 10 19:17, Avijit Ghosh wrote: VIM seems to be behaving improperly executing the 'cw' command when the cursor is positioned on a block of contiguous white-space characters. It is changing *only* the character it is positioned on (instead of changing up to the last white-space in the block). Consider the following example text (please read using fixed-width font): alpha beta ^ Cursor here If I type 'cwESC', I get: alpha beta I expect, based on using Win32 native VIM 7.2, Cygwin VIM 6.x, and other VIM/vi on Unix platforms -- and also on behavior or 'dw' or just 'w' on *this* version of VIM: alphabeta That is, I expect 'cw' to be equivalent in general to 'dwi', and 'cwESC' to be equivalent to 'dw' --- this is not the case any more, it seems. -- 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: [1.7] Possible dynamic linker error
David Korn wrote: - I ran rebaseall on cygwin and all of the dlls in questions. It still crashes, but now crashes somewhere else. Ah! Reinstall your libstdc++ dll. Yaakov spotted that the 4.3.4-1 libstdc++ dll isn't rebaseable, as it turns out there's a bug in LD(*). I'm just doing final testing on a new release to fix the problem, but until that's out, the current libstdc++ dll will have to be reinstalled if it gets rebased. O.k. Copying 'cygstdc++-6.dll' did restore the original problem (as well as allowed the statically-linked executable to work again). libraries were compiled by me on the same machine using gcc4.3.4). When looking at the problem using GDB, it says it is now going to jump to subroutine A (finishConstruction()), but instead jumps to subroutine B (edm::ValueMapdouble::operator+=). This could be just the ordinary sort of thing that goes on when you compile with optimisation (and hence inlining) turned on. It looks from the earlier lines like it's just constructed a std::map as part of the PluginFactory or PluginFactoryBase constructors, so if that edm::ValueMap is a derivation of std::map it might well be that finishConstruction() is correctly invoking the += operator to append an item, and gdb is showing you the source of the inlined operator function. So I think first thing you need to do is figure out if maybe it's actually going the right code path, and has gotten something wrong with the value of j. Check the value of $eip before and after that final step command and find out exactly where you're running. From my friend Chris: The edm::ValueMap is not a 'derivation' of std::map, in fact it doesn't even use it. Also, finishConstruction() is not inlined [since it is defined in a .cc file] and therefore has to be called directly. So between the fact that the statically linked executable works and the above, it really does look like the code is jumping to the wrong function. I'm attaching the another gdb session where I look at $eip before and after to see if that provides any clues. Do you have any other ideas? Is the dll simply too big? Thanks, Charles * statically linked just means that we don't dynamically link to the 400 Mb dll, but rather compile in those .o files. We still statically link to the rest of the libraries shown in: http://cygwin.com/ml/cygwin/2009-12/msg00275.html p.s. Since I'm not on the mailing list, is there a way to have a particular message sent to me so I can respond to it and not screw up the threading? cpla...@hagrid gdb ./cmsShow_dynamic.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-cygwin... (gdb) run Starting program: /mount/cplagerdoc/cplager/build/cmsShow34g/cmsShow_dynamic.exe [New thread 4464.0x1140] [New thread 4464.0x135c] Program received signal SIGSEGV, Segmentation fault. 0x3e61a46a in edm::helper::Filleredm::ValueMapdouble ::add () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSDataFormats.dll (gdb) break 'edmplugin::PluginFactoryFWRPZDataProxyBuilderBase* ()()::get ()' Breakpoint 1 at 0x69d6e580: file src/Fireworks/Core/src/FWRPZDataProxyBuilderBaseFactory.cc, line 20. (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /mount/cplagerdoc/cplager/build/cmsShow34g/cmsShow_dynamic.exe [New thread 4488.0xa28] Error in re-setting breakpoint 1: Function edmplugin::PluginFactoryFWRPZDataProxyBuilderBase* ()()::get () not defined. [New thread 4488.0xaa0] Program received signal SIGSEGV, Segmentation fault. 0x3e61a46a in edm::helper::Filleredm::ValueMapdouble ::add () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSDataFormats.dll (gdb) where #0 0x3e61a46a in edm::helper::Filleredm::ValueMapdouble ::add () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSDataFormats.dll #1 0x3e61a828 in edm::helper::Filleredm::ValueMapdouble ::Filler () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSDataFormats.dll #2 0x3e6bf8fa in edm::ValueMapdouble::add () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSDataFormats.dll #3 0x3e6bfae0 in edm::ValueMapdouble::operator+= () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSDataFormats.dll #4 0x3864d07b in edmplugin::PluginFactoryFWRPZDataProxyBuilderBase* ()()::PluginFactory () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSShow.dll #5 0x384ee5bb in edmplugin::PluginFactoryFWRPZDataProxyBuilderBase* ()()::get () from /mount/cplagerdoc/cplager/build/cmsShow34g/libCMSShow.dll #6 0x3864c223 in edmplugin::PluginFactoryFWRPZDataProxyBuilderBase*
Re: [1.7] Possible dynamic linker error
Charles Plager wrote: David Korn wrote: - I ran rebaseall on cygwin and all of the dlls in questions. It still crashes, but now crashes somewhere else. Ah! Reinstall your libstdc++ dll. Yaakov spotted that the 4.3.4-1 libstdc++ dll isn't rebaseable, as it turns out there's a bug in LD(*). I'm just doing final testing on a new release to fix the problem, but until that's out, the current libstdc++ dll will have to be reinstalled if it gets rebased. O.k. Copying 'cygstdc++-6.dll' did restore the original problem (as well as allowed the statically-linked executable to work again). Wait, what? Are you employing the Chewbacca defense here? :-) From my friend Chris: The edm::ValueMap is not a 'derivation' of std::map, in fact it doesn't even use it. Also, finishConstruction() is not inlined [since it is defined in a .cc file] and therefore has to be called directly. 'k, that rules that one out. So between the fact that the statically linked executable works and the above, it really does look like the code is jumping to the wrong function. I'm attaching the another gdb session where I look at $eip before and after to see if that provides any clues. Do you have any other ideas? Is the dll simply too big? Ping! (lightbulb appearing noise) Do you suppose there are 65536 exports in the DLL? That will /definitely/ break, and will do so in a random-jumps-into-space sort of way. * statically linked just means that we don't dynamically link to the 400 Mb dll, but rather compile in those .o files. We still statically link to the rest of the libraries shown in: http://cygwin.com/ml/cygwin/2009-12/msg00275.html Ah, that explains the Chewbacca defense! p.s. Since I'm not on the mailing list, is there a way to have a particular message sent to me so I can respond to it and not screw up the threading? Yeah. You need to figure out the message number by looking in the archive at the headers of the raw text view of the post in question. For instance, your post which I'm replying to here is at: http://cygwin.com/ml/cygwin/2009-12/msg00397.html Following the Other format: Raw text link in the nav header takes us to: http://cygwin.com/cgi-bin/get-raw-msg?listname=cygwindate=2009-12msgid=4B228BB8.8060107%40fnal.gov and then you're looking for the number embedded in the From/Return path headers: From cygwin-return-157411-listarch-cygwin=sourceware dot org at cygwin dot com Fri Dec 11 18:14:07 2009 Return-Path: cygwin-return-157411-listarch-cygwin=sourceware dot org at cygwin dot com So that was message #157411. To get an individual copy sent to you, send blank email to cygwin-get.157...@x.y (where X is cygwin and Y is com, to fool spam harvesters). You can then reply to the returned copy and the threading will all work right. For full instructions on how to send commands to the list manager software, send blank email to cygwin-i...@x.y, with the same X and Y as before. cheers, DaveK -- 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
[1.7] hard link error on FAT32 with zsh
Hi, I was testing the latest 1.7 DLL snapshot (1.7.2s(0.218/5/3) 20091209 12:02:30) and the current 1.7 one (that you get from setup-1.7.exe). I am starting zsh and get the following error: zsh: failed to create hard link as lock file /home/thorsten/.zhistory.LOCK: operation not permitted. This relates to the following setting in .zshrc: HISTFILE=~/.zhistory. Zsh starts but no history is available. Cygwin is located on a FAT32 thumb drive. Bash does not exihibit the error. Thorsten -- 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
[ANNOUNCEMENT] Updated: stable compiler package gcc4-4.3.4-3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This release is an incremental update to the stable release. As with the previous release, the Java and Ada compilers are known to have some bugs, but the core compiler and primary languages (C, C++ and Fortran) are all working well enough to be considered stable, conformant to the relevant language specs, and production-ready. IMPORTANT NOTE ON THE ALTERNATIVES SYSTEM: The alternatives system (see 'man alternatives') is used with this package to select the default system compiler that is invoked under the plain 'gcc' (or 'g++', etc.) name without any -3 or -4 suffix. Since the last release, the default system compiler (previously gcc-3) is now switched to gcc-4 permanently. All future distro packages will be built with this compiler, and indeed many already have been for some time, so no significant disruption should arise. However, for those who would prefer to retain gcc-3 as their system default compiler, it is easy to change the alternatives selection. Generally, you should switch all the compiler packages simultaneously to either -3 or -4 versions; mixed usages aren't guaranteed to work. To this end, two shell scripts are installed by this release: /usr/bin/set-gcc-default-3.sh /usr/bin/set-gcc-default-4.sh These can be invoked to switch all the alternatives for the compiler en masse. Note that not all language compilers exist in both -3 and -4 versions; fortran changes names between the two versions, so doesn't clash, and D and Pascal only exist in -3 versions currently. IMPORTANT NOTE FOR GNAT USERS: The GNAT tools do not understand the version-suffix system used by the other gcc compilers in the package. If you attempt to invoke gnatmake-4, for example, it will attempt to invoke plain unsuffixed names like gnatchop, gnatbind as subexecutables. In consequence, only the currently-selected version of gnat chosen by the alternatives system can run correctly at any given time; you should always configure the GNAT alternatives to select as default the version you wish to use, by invoking one of the two scripts mentioned above. COMING NEXT: The to-do list for the next release (expected within a few weeks) currently stands at: - - Reconfigure libstdc++ locale settings to support full UTF-8 locales. If there's anything else you think is important, please contact the Cygwin mailing list with your suggestion. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a full current version release, any gcc packages you currently have installed will be automatically selected to update, but you'll need to select the Devel category to see gcc and friends if you don't have them already installed. NEWS From the README: gcc4-4.3.4-3 - -- This is the second full stable production release of the GCC 4 compiler package for Cygwin. All the major runtime libraries are implemented as DLLs as well as static archives. It can fully co-exist side-by-side with the older Cygwin gcc-3.4.4 series compiler. All languages are supported, although Ada and Java remain works-in-progress. End-of-life for Cygwin-1.5. === This version is not released for the Cygwin-1.5 series. All future effort will go into developing the compiler for Cygwin-1.7 and beyond. Building the compiler from source under 1.5 is unsupported and unmaintained, but possible; however, you would need to build yourself an updated version of binutils from the sourceware.org CVS repository, and you would need to apply the modern-binutils-on-cygwin-1.5-default-pseudo-reloc-fix.diff patch found in the CYGWIN-PATCHES directory of this source release. Also it would be unsupported and unmaintained, so if you're not comfortable doing this sort of thing on your own, you probably don't want to start. Now would be a good time to try 1.7, anyway :) It works really well. What happened to gcc4-4.3.4-2? == I skipped a release number. The -2 release is reserved for any theoretical upgrade to the 1.5 compiler that might ever be needed somewhere sometime. Java users need an additional download to compile source to bytecode. = As part of its
Re: Updated: stable compiler package gcc4-4.3.4-3
Dave Korn wrote: I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. A well written post. Thank you. One thing that I noticed re /etc/alternatives with regard to CodeBlocks and it may have the same effect on other IDES, is that I had to explicitly point CodeBlocks to the gcc-n executable. CodeBlocks automatically 'found' and populated itself with gcc, but invocation fails with dtest - Debug uses an invalid compiler. Skipping... Nothing to be done. -- 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
cygwin install fails with cygbase mismatch during install
This machine used to run cygwin fine till I upgraded to WinXP (a few months ago). Some history. The machine started its life as a well equipped Win95 machine. It has been modified and upgraded, to the point that the only thing left from the original machine is the case and a 5-1/2 floppy drive (no longer connected). I have been able to run cygwin and its x-windows relatives since Win98. Over the years, I upgraded to Win2K, installed many new motherboards and processors, replaced/added hdd's with no impact on cygwin. A few months ago I upgraded to WinXP (I don't like to rush into things :-)). At that time, the version of cygwin that I had installed started behaving strangely - commands would randomly crash upon invocation, x windows would hang - things that had not happened over the past 10 years or so. I decided it was time to upgrade cygwin. That is when the fun started. I downloaded the latest version of setup.exe, did an install (from ftp at georgia tech) and everything just stopped working, including some apps that used cygwin1.dll. To make a long story short, I deleted EVERYTHING associated with cygwin from all of the hdd's on the system, edited the registry to remove all occurrences of anything to do with cygwin, cygnus, etc. and did my best to make this a virgin system to cygwin. I reloaded setup.exe, installed the plain vanilla (default) version (from University of Michigan if I recall correctly) and tried it out. No luck. I repeated the process (deleting all files, cleaning the registry, etc) then downloaded form Georgia Tech again. Failure. After much web searching I found the diagnostics and logs I would need to trace the problem. Interestingly, from the middle to the end of setup.log.full, was 600KB of *** fatal error - cygheap base mismatch detected - 0xAF88E0/0xAA88E0. Just to make sure, I repeated the process again (I am a glutton for punishment) making sure that I did not issue any cygwin commands, checked the log immediately after setup finished, and saw the same thing. I also ran cygcheck -s -v -r cygcheck.out (attached). The error reporting how-to recommended that I attach cygcheck.out but made no mention of setup.log.full (which is rather large) so I did not attach that file. I really can't reformat and restart with a clean WinXP installation, there is so much history on this machine that restoring from backups (yes I have them) would not work - I can't find some of the original application installation disks. Can anyone help me get cygwin installed? Thanks in advance, donz http://old.nabble.com/file/p26753764/cygcheck.out cygcheck.out -- View this message in context: http://old.nabble.com/cygwin-install-fails-with-cygbase-mismatch-during-install-tp26753764p26753764.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Updated: stable compiler package gcc4-4.3.4-3
On Fri, Dec 11, 2009 at 06:41:06PM -0500, Reid Thompson wrote: Dave Korn wrote: I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. A well written post. Thank you. One thing that I noticed re /etc/alternatives with regard to CodeBlocks and it may have the same effect on other IDES, is that I had to explicitly point CodeBlocks to the gcc-n executable. CodeBlocks automatically 'found' and populated itself with gcc, but invocation fails with dtest - Debug uses an invalid compiler. Skipping... Nothing to be done. Well, sure. I'll bet that CodeBlocks isn't a Cygwin application and, so, does not understand Cygwin symlinks. cgf -- 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: Segmentation Fault in Cross-Compilers
Matthew Iselin wrote: I've been running into a persistent segmentation fault in any GCC cross-compiler I build. I'm building a GCC 4.4.1 compiler for my project, which has worked properly in the past. This week it stopped working, right after I updated my Cygwin installation (new cygwin1.dll, I believe): Compiling build/src/user/applications/apptest/main.obj i686-pedigree-gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. I'm not sure what's wrong here, any ideas would be much appreciated. I've attached the generated stackdump as well as my cygcheck output. I suspect you're running into the libstdc++ dll can't be rebased problem. Try upgrading to the new gcc4 (plus associated runtimes), with any luck that will solve it for you. cheers, DaveK -- 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: Segmentation Fault in Cross-Compilers
I suspect you're running into the libstdc++ dll can't be rebased problem. Try upgrading to the new gcc4 (plus associated runtimes), with any luck that will solve it for you. cheers, DaveK Hi Dave, Thanks for the suggestion. I reinstalled the gcc4 and libstdc++ related packages (they were already installed) and everything seems to be working now. Cheers, Matt -- 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
BASH Shell - Configuration Problem?
I haven't used cygwin or bash in 5 years, but I need to write a bash script
for my ISP to test JavaMail. I can't get simple things to work, so I'm
wondering if maybe I have a bash shell config issue. I did update cygwin to
the latest.
Here's a script I have written:
-
#!/bin/bash
export JAVA_HOME=/usr/lib/jvm/jdk1.6.0_07
export TEST_HOME=.
export PATH=.:${JAVA_HOME}/bin:${PATH}
export TEST_JAR=${TEST_HOME}/test.jar
export JAR1=${TEST_HOME}/log4j.jar
export JAR2=${TEST_HOME}/commons-logging.jar
export JAR3=${TEST_HOME}/commons-discovery.jar
export JAR4=${TEST_HOME}/mail.jar
export JAR5=${TEST_HOME}/activation.jar
export CLASSPATH=$TEST_JAR;$JAR1;$JAR2;$JAR3;$JAR4;$JAR5
echo $CLASSPATH
#
${JAVA_HOME}/bin/java -version
$JAVA_HOME/bin/java -Xms128m -Xmx128m com.bob.test.JavaMailTest
--
When I run this from my cygwin bash shell, here's what I get:
bash-3.2$ ./test_javamail.sh
/activation.jarery.jar
/bin/java: No such file or directoryb/jvm/jdk1.6.0_07
/bin/java: No such file or directoryb/jvm/jdk1.6.0_07
Notice how the echo of the classpath is an overwrite of JAR3 path by JAR5
path.
Also, a similar overwrite when I try to get the java version, and run my
tester.
Any ideas?
I'm open to writing this in any other script, so please let me know if I
should be using a sh script or something else.
Thanks,
--Bob
--
View this message in context:
http://old.nabble.com/BASH-Shell---Configuration-Problem--tp26753996p26753996.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: BASH Shell - Configuration Problem?
On 2009-12-11, rgc3679 wrote: I haven't used cygwin or bash in 5 years, but I need to write a bash script for my ISP to test JavaMail. I can't get simple things to work, so I'm wondering if maybe I have a bash shell config issue. I did update cygwin to the latest. [...] Notice how the echo of the classpath is an overwrite of JAR3 path by JAR5 path. Also, a similar overwrite when I try to get the java version, and run my tester. Any ideas? Thanks for all the details. That really helps. It looks to me as though your script file has CR-LF (DOS) line endings rather than LF (Unix) line endings. The current version of Cygwin's bash sees only the LF line endings and includes the CR as part of the script. You can use the d2u utility to fix this. HTH, Gary -- 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: Segmentation Fault in Cross-Compilers
Matthew Iselin wrote: I suspect you're running into the libstdc++ dll can't be rebased problem. Try upgrading to the new gcc4 (plus associated runtimes), with any luck that will solve it for you. Thanks for the suggestion. I reinstalled the gcc4 and libstdc++ related packages (they were already installed) and everything seems to be working now. According to your cygcheck you have version 4.3.4-1; the latest is 4.3.4-3 (it may not be on your first mirror of choice yet but it's certainly started propagating to a fair number of them). Reinstalling will solve the problem temporarily for 4.3.4-1, but it will recur if you run rebaseall, and may occur randomly at runtime anyway if an MS update changes the bases of any of those many DLLs you listed in the cygcheck-cc1 output. Upgrading to the new version avoids both these potential future problems. cheers, DaveK -- 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: [1.7] cvs over ssh hangs on completion
On Tue, Dec 1, 2009 at 5:24 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 30 11:23, Corinna Vinschen wrote: On Nov 26 22:42, Jeremy Hetzler wrote: I have cvs on a client machine connecting to a host over ssh. The cvs procedure finishes, but the connection does not terminate until I hit ctrl-c. The cvs process is then left running on the host. Regular ssh connections (ie interactive login) do not have this problem. The host machine is Cygwin 1.7.0 on Windows 7; the client is Cygwin 1.5.25 on Windows XP. Attached is a cygcheck from the host and debug output from sshd. Is there anything I can do to fix this? Dunno, yet. Is this a new problem? In other words, did this effect start to occur with 1.7.0-65, or do you already suffer calmly for a longer time? Previously the server was 1.5.25 on XP. That worked fine (and still works fine). When I moved to Win 7 and 1.7 the problem appeared. Running 1.5.25 under Windows 7 on the server solves the problem. Whatever the problem is, it only appears under 1.7. I tried the same scenario, a cvs server running under Cygwin 1.7 and a client running under Cygwin 1.5.25. I tried both socket types as introduced with 1.7.0-65, and I can't reproduce the aforementioned effect. http://cygwin.com/acronyms/#BLODA? Disabling Windows Defender and Windows Firewall has no effect. I'm not running any of the other programs mentioned there. -- 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
where is my /usr/dict/words or /usr/share/dict/words on cygwin? (1.7)
Hi; I update frequently. I always get everything from the standard cygwin mirrors. I have not seen /usr/share/dict/words or /usr/dict/words for quite some time now. I really like this package and it is not installed on any of our proprietary systems at work and it is not installed on any of our Linux machines at work, but it is on a FreeBSD machine at work that I cannot always get access to. Why isn't it on my cygwin installation (1.7) when I ask for EVERYTHING to be installed? Thanks, Ken Wolcott -- 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: [1.7] cvs over ssh hangs on completion
On Fri, Dec 11, 2009 at 11:11 PM, Jeremy Hetzler jeremyhetz...@gmail.com wrote: On Tue, Dec 1, 2009 at 5:24 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Nov 30 11:23, Corinna Vinschen wrote: On Nov 26 22:42, Jeremy Hetzler wrote: I have cvs on a client machine connecting to a host over ssh. The cvs procedure finishes, but the connection does not terminate until I hit ctrl-c. The cvs process is then left running on the host. Regular ssh connections (ie interactive login) do not have this problem. The host machine is Cygwin 1.7.0 on Windows 7; the client is Cygwin 1.5.25 on Windows XP. Attached is a cygcheck from the host and debug output from sshd. Is there anything I can do to fix this? Dunno, yet. Is this a new problem? In other words, did this effect start to occur with 1.7.0-65, or do you already suffer calmly for a longer time? Previously the server was 1.5.25 on XP. That worked fine (and still works fine). When I moved to Win 7 and 1.7 the problem appeared. Running 1.5.25 under Windows 7 on the server solves the problem. Whatever the problem is, it only appears under 1.7. I tried the same scenario, a cvs server running under Cygwin 1.7 and a client running under Cygwin 1.5.25. I tried both socket types as introduced with 1.7.0-65, and I can't reproduce the aforementioned effect. http://cygwin.com/acronyms/#BLODA? Disabling Windows Defender and Windows Firewall has no effect. I'm not running any of the other programs mentioned there. -- Jeremy One more thing. When I make a connection to 1.5.25 sshd, an extra console window appears on the server for the duration of the connection. I'm running sshd from the command line so maybe it wouldn't happen as a service. It doesn't happen under 1.7 in any configuration. Is there a way to uninstall the 1.7 sshd service? I'd like to downgrade it to 1.5.25 as a workaround. Thanks, 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: Slow GCC under 64-bit?
On 11/12/2009 10:59 a.m., Pedro DeKeratry wrote: I experience very slow GCC compilation times on win7 64bit computer as compared to a 3 yr old computer running winXP. The win7 machine has has a much newer/faster CPU and 2x the memory as the XP machine. The slowness exists on Cygwin versions 1.5.x and 1.7. I haven't figured out what the cause is much less a fix. If your new machine is multi-core you might see some benefit if you use the parallel make option with your makefiles - this will run multiple compile steps at the same time, achieving speedup on multi-core systems. On GNU make, for example, you can run 4 jobs at once with: make -j 4 Cheers, Nicholas Sherlock -- 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: where is my /usr/dict/words or /usr/share/dict/words on cygwin? (1.7)
2009/12/12 Kenneth Wolcott: I update frequently. I always get everything from the standard cygwin mirrors. I have not seen /usr/share/dict/words or /usr/dict/words for quite some time now. I really like this package and it is not installed on any of our proprietary systems at work and it is not installed on any of our Linux machines at work, but it is on a FreeBSD machine at work that I cannot always get access to. Why isn't it on my cygwin installation (1.7) when I ask for EVERYTHING to be installed? Because no-one has volunteered to package it? Certainly I can't find it in the package list, either on 1.5 or 1.7. Perhaps you'd previously copied it manually from elsewhere? Andy -- 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
Updated: smartmontools-5.39-1
Version 5.39-1 of smartmontools has been uploaded. http://smartmontools.sourceforge.net/ Changes include: - Support for USB devices with Cypress, JMicron and Sunplus USB bridges - USB device type autodetection for some devices, see http://sourceforge.net/apps/trac/smartmontools/wiki/Supported_USB-Devices - smartctl option '-l xerror' to print ATA SMART Extended Comprehensive Error Log - smartctl option '-l xselftest' to print ATA SMART Extended Self-test Log - smartctl option '-l sataphy' to print SATA Phy Event Counters - smartctl option '-l sasphy' to print SAS device phy information - smartctl options '-l gplog,...' and '-l smartlog,...' to print any log page - smartctl option '-x' to print all extended info if available (The above require IOCTL_ATA_PASS_THROUGH in driver or 48-bit pass-through support in USB bridge) - smartctl prints SCSI load/unload cycle counts - Improve display of huge raw values of some SMART attributes - Option '-v ID,RAW_FORMAT,ATTR_NAME' to add new vendor specific attributes - Support for SSD drives using 64-bit raw attributes - Many additions to drive database - New simplified syntax for drive database - Drive database read from file (/usr/share/smartmontools/drivedb.h, /etc/smart_drivedb.h) - smartd can now handle attributes 197 and 198 with increasing raw values - smartd logs changes of self-test execution status - smartd directive '-n powermode,N' to limit the number of skipped checks - smartd flag '!' for '-r' and '-R' directives to log changes as critical - smartd supports scheduled Selective Self-Tests - Self-tests scheduled during system downtime or disk standby are run after next startup - smartd stores internal state until next startup (/var/lib/smartmontools/smartd.MODEL-SERIAL.ata.state) - smartd option '-A PREFIX' to log attributes at each check cycle For a full list of changes see NEWS and CHANGELOG in /usr/share/doc/smartmontools Please read the Windows and Cygwin sections in the files INSTALL and WARNINGS. For open issues see http://sourceforge.net/apps/trac/smartmontools/report/1 Description: Smartmontools contains utility programs (smartctl, smartd) to control/monitor storage systems using the Self-Monitoring, Analysis and Reporting Technology System (S.M.A.R.T.) built into most modern ATA and SCSI disks. In many cases, these utilities will provide advanced warning of disk degradation and failure. Smartctl is a command line utility designed to perform tasks such as printing the SMART self-test and error logs, enabling and disabling SMART automatic testing, and initiating device self-tests. Smartd is a daemon that monitors the drives every 30 minutes (configurable), logs SMART errors and changes of SMART Attributes via the syslog interface. Smartd can also be configured to schedule self-tests and send email warnings or run other scripts if problems are detected. On Cygwin, smartd can be run as a windows service via cygrunsrv. Christian Franke -- To update your installation, click on the Install or update now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin at cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com at cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: stable compiler package gcc4-4.3.4-3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This release is an incremental update to the stable release. As with the previous release, the Java and Ada compilers are known to have some bugs, but the core compiler and primary languages (C, C++ and Fortran) are all working well enough to be considered stable, conformant to the relevant language specs, and production-ready. IMPORTANT NOTE ON THE ALTERNATIVES SYSTEM: The alternatives system (see 'man alternatives') is used with this package to select the default system compiler that is invoked under the plain 'gcc' (or 'g++', etc.) name without any -3 or -4 suffix. Since the last release, the default system compiler (previously gcc-3) is now switched to gcc-4 permanently. All future distro packages will be built with this compiler, and indeed many already have been for some time, so no significant disruption should arise. However, for those who would prefer to retain gcc-3 as their system default compiler, it is easy to change the alternatives selection. Generally, you should switch all the compiler packages simultaneously to either -3 or -4 versions; mixed usages aren't guaranteed to work. To this end, two shell scripts are installed by this release: /usr/bin/set-gcc-default-3.sh /usr/bin/set-gcc-default-4.sh These can be invoked to switch all the alternatives for the compiler en masse. Note that not all language compilers exist in both -3 and -4 versions; fortran changes names between the two versions, so doesn't clash, and D and Pascal only exist in -3 versions currently. IMPORTANT NOTE FOR GNAT USERS: The GNAT tools do not understand the version-suffix system used by the other gcc compilers in the package. If you attempt to invoke gnatmake-4, for example, it will attempt to invoke plain unsuffixed names like gnatchop, gnatbind as subexecutables. In consequence, only the currently-selected version of gnat chosen by the alternatives system can run correctly at any given time; you should always configure the GNAT alternatives to select as default the version you wish to use, by invoking one of the two scripts mentioned above. COMING NEXT: The to-do list for the next release (expected within a few weeks) currently stands at: - - Reconfigure libstdc++ locale settings to support full UTF-8 locales. If there's anything else you think is important, please contact the Cygwin mailing list with your suggestion. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is a full current version release, any gcc packages you currently have installed will be automatically selected to update, but you'll need to select the Devel category to see gcc and friends if you don't have them already installed. NEWS From the README: gcc4-4.3.4-3 - -- This is the second full stable production release of the GCC 4 compiler package for Cygwin. All the major runtime libraries are implemented as DLLs as well as static archives. It can fully co-exist side-by-side with the older Cygwin gcc-3.4.4 series compiler. All languages are supported, although Ada and Java remain works-in-progress. End-of-life for Cygwin-1.5. === This version is not released for the Cygwin-1.5 series. All future effort will go into developing the compiler for Cygwin-1.7 and beyond. Building the compiler from source under 1.5 is unsupported and unmaintained, but possible; however, you would need to build yourself an updated version of binutils from the sourceware.org CVS repository, and you would need to apply the modern-binutils-on-cygwin-1.5-default-pseudo-reloc-fix.diff patch found in the CYGWIN-PATCHES directory of this source release. Also it would be unsupported and unmaintained, so if you're not comfortable doing this sort of thing on your own, you probably don't want to start. Now would be a good time to try 1.7, anyway :) It works really well. What happened to gcc4-4.3.4-2? == I skipped a release number. The -2 release is reserved for any theoretical upgrade to the 1.5 compiler that might ever be needed somewhere sometime. Java users need an additional download to compile source to bytecode. = As part of its
