[ITP-adopt] stunnel-4.20-1
stunnel was abandoned for Cygwin back in the fall. I've packaged the latest version for Cygwin (URLs below) and would like to maintain it. stunnel is a program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer). stunnel can allow you to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by having stunnel provide the encryption, requiring no changes to the daemon's code. Changes since the last Cygwin release: - updated to version 4.20 - moved stunnel executable from /usr/sbin to /usr/bin, to comply with the Linux Filesystem Hierarchy Standard - added cygstunnel.dll - changed to cygport build method - new Cygwin maintainer Please note that, although libstunnel.so (i.e. cygstunnel.dll) is included in this package (as Corinna requested back in October; http://www.mail-archive.com/cygwin-apps@cygwin.com/msg17175.html), its use is undocumented AFAICT and so I haven't tried to test it. I guess that something like LD_PRELOAD=/usr/bin/libstunnel.dll should provide transparent proxy support for clients via stunnel, but I don't really know how or if it would work. If people want me to leave that in so they can test it, fine. If not, fine too and I'll take it out. Please review and, if the package is found suitable, upload. Thanks, Andrew. wget \ http://home.comcast.net/~andrex/cygwin/stunnel/setup.hint \ http://home.comcast.net/~andrex/cygwin/stunnel/stunnel-4.20-1.tar.bz2 \ http://home.comcast.net/~andrex/cygwin/stunnel/stunnel-4.20-1-src.tar.bz2
Re: XWin 100% CPU usage (Remote Desktop)
I worked on this for a long time since trying vista and here's my solution CYGWIN=title server itty binmode glob tty I believe that some arrangement of CYGWIN args cause troubles, but I can't verify which, and I also believe I had ntsec in there before. It would run for a while, althouhg process explorer would show 9-10 thousand context switches per second for XWin.exe, then eventually it would go to XWin.exe running full blast an unresponsive until I killed it. Hope it helps, dkr -- 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: XWin 100% CPU usage (Remote Desktop)
David Raila wrote: I worked on this for a long time since trying vista and here's my solution CYGWIN=title server itty binmode glob tty I believe that some arrangement of CYGWIN args cause troubles, but I can't verify which, and I also believe I had ntsec in there before. It would run for a while, althouhg process explorer would show 9-10 thousand context switches per second for XWin.exe, then eventually it would go to XWin.exe running full blast an unresponsive until I killed it. 'binmode' and 'glob' are on by default so you don't need to set these. The same is true for 'ntsec'. There is no 'itty' option for CYGWIN. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
src/winsup/cygwin ChangeLog fhandler_socket.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-02-20 09:48:31 Modified files: winsup/cygwin : ChangeLog fhandler_socket.cc Log message: * fhandler_socket.cc (fhandler_socket::bind): Remove printing wrong errno in debug output. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3757r2=1.3758 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srcr1=1.204r2=1.205
winsup/cygwin exceptions.cc sync.h winsup.h Ch ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2007-02-20 14:31:27 Modified files: cygwin : exceptions.cc sync.h winsup.h ChangeLog Log message: * exceptions.cc (_cygtls::signal_exit): Only call myself.exit when when exit_state indicates that we've visited do_exit. * sync.h (lock_process::lock_process): Use renamed exit_state - ES_PROCESS_LOCKED. * winsup.h: Rename ES_MUTO_SET to ES_PROCESS_LOCKED. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/exceptions.cc.diff?cvsroot=uberbaumr1=1.299r2=1.300 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sync.h.diff?cvsroot=uberbaumr1=1.37r2=1.38 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/winsup.h.diff?cvsroot=uberbaumr1=1.198r2=1.199 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3758r2=1.3759
src/winsup/cygwin ChangeLog cygwin.din posix_i ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-02-20 15:48:04 Modified files: winsup/cygwin : ChangeLog cygwin.din posix_ipc.cc pthread.cc syscalls.cc thread.cc thread.h winsup/cygwin/include: semaphore.h winsup/cygwin/include/cygwin: version.h Log message: * cygwin.din (sem_unlink): Export. * posix_ipc.cc: Include thread.h and semaphore.h. Remove TODO comment. (ipc_names): Add max_len member. Set to maximum length of the path before tacking on the prefix path. Set prefix path for named semaphors to /dev/shm, as on Linux. (enum ipc_type_t): Change sem to semaphore to avoid name conflicts. (check_path): Detect empty paths. Use ipc_names's max_len member. Use __small_sprintf to create full object path name. Special case semaphores. (ipc_cond_init): Drop superfluous strcpy. (class ipc_flock): New class to simplify file locking in subsequent code. (struct mq_hdr): Raise size of mqh_uname to allow adding a unique LUID to the name. (mq_open): Fix formatting. Create unique synchronization object names using AllocateLocallyUniqueId. (struct sem_finfo): New structure defining named semaphore file content. (sem_open): Move here. Rework implementation to allow kernel persistent implementation of POSIX named semaphores. (_sem_close): Implement sem_close. (sem_close): Move here. Just call _sem_close with do_close parameter set to true. (sem_unlink): New function. * pthread.cc (mangle_sem_name): Remove. (sem_open): Move to posix_ipc.cc. (sem_close): Ditto. * syscalls.cc (close_all_files): Call semaphore::terminate here. * thread.cc: Fix formatting. Rearrange semaphore functions so that they are close together. (semaphore::semaphore): Rework to play nicely with new named semaphore implementation. (semaphore::_terminate): Call _sem_close if semaphore is a named semaphore. (semaphore::destroy): Don't destroy named semaphores. Return EINVAL instead. (semaphore::close): Only destroy named semaphores. Return EINVAL otherwise. (semaphore::open): Rework to play nicely with new named semaphore implementation. Loop through existing semaphores to be able to return same sem_t pointer as a former call on the same named semaphore. (semaphore::getinternal): New function called from _sem_close. * thread.h (class List): Make mx and head public. (class semaphore): Fix formatting. Align method declarations with implementation in thread.cc. Add members used for named semaphores. (semaphore::terminate): New static method. * include/semaphore.h: Redefine SEM_FAILED. Fix formatting. (sem_unlink): Add declaration. * include/cygwin/version.h: Bump API minor number. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3759r2=1.3760 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.170r2=1.171 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/posix_ipc.cc.diff?cvsroot=srcr1=1.3r2=1.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pthread.cc.diff?cvsroot=srcr1=1.29r2=1.30 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.433r2=1.434 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.199r2=1.200 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.h.diff?cvsroot=srcr1=1.103r2=1.104 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/semaphore.h.diff?cvsroot=srcr1=1.5r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.239r2=1.240
src/winsup/utils ChangeLog cygcheck.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-02-20 16:41:54 Modified files: winsup/utils : ChangeLog cygcheck.cc Log message: * cygcheck.cc (dump_sysinfo): Add not supported to osname on 9x machines. Drop not supported for Vista. Drop Longhorn text for now. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.371r2=1.372 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/cygcheck.cc.diff?cvsroot=srcr1=1.93r2=1.94
rlogin broken
Hi, I got the following problem : rlogin : No Buffer space available rlogin: connection closed. I saw that this problem was reported in the following references : References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Where can I find the fix please ? Thanks in advance. Regards Patrice Dronnier Product Engineering(Embedded image moved to file: pic23281.gif) Bull, Architect of an Open World TM Phone: +33 (0)4 76 29 71 12 Fax: +33 (0)4 76 29 72 49 Mail: [EMAIL PROTECTED] This e-mail contains material that is confidential for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. pic23281.gif Description: GIF image -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rlogin broken
On Feb 20 11:09, [EMAIL PROTECTED] wrote: Hi, I got the following problem : rlogin : No Buffer space available rlogin: connection closed. I saw that this problem was reported in the following references : References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Where can I find the fix please ? Download the latest Cygwin release using setup. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.24 unable to access files via root / (forward slash)
Hi, I'm trying to access files for reading via the / directive, i.e. vi /usr/foo.txt However, this will not open foo.txt, vi creates a new file in the current directory instead. I can cd to the /usr directory and open the file with vi usr.txt. I'm using vi as an example, I'm actually trying to compile files with a gcc variant, and it can't access files the the / path either. I've checked with the mount command that / is mounted, and it reports: D:\cygwin_root on / type system (binmode) Output from ls -lg /usr shows -rwxrwxrwx 1 mkgroup-l-d 13 Feb 20 13:33 foo.txt Which seems ok from what I've read? I've attached the output from cygcheck using cygcheck -srvv. Apologies if I'm missing something really simple here. http://www.nabble.com/file/6655/cygcheck.out cygcheck.out Thanks in advance, Jeff. -- View this message in context: http://www.nabble.com/1.5.24-unable-to-access-files-via-root---%28forward-slash%29-tf3260586.html#a9061924 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24 unable to access files via root / (forward slash)
On Tue, Feb 20, 2007 at 05:44:51AM -0800, Jeff2007 wrote: Hi, I'm trying to access files for reading via the / directive, i.e. vi /usr/foo.txt However, this will not open foo.txt, vi creates a new file in the current directory instead. I can cd to the /usr directory and open the file with vi usr.txt. I'm using vi as an example, I'm actually trying to compile files with a gcc variant, and it can't access files the the / path either. I've checked with the mount command that / is mounted, and it reports: D:\cygwin_root on / type system (binmode) Output from ls -lg /usr shows -rwxrwxrwx 1 mkgroup-l-d 13 Feb 20 13:33 foo.txt Which seems ok from what I've read? I've attached the output from cygcheck using cygcheck -srvv. Apologies if I'm missing something really simple here. http://www.nabble.com/file/6655/cygcheck.out cygcheck.out Well, from the cygcheck output, it seems like you aren't actually running a cygwin version of vim, so it is unlikely that 'vi' would understand cygwin's mount table. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24 unable to access files via root / (forward slash)
Jeff2007 wrote: I'm trying to access files for reading via the / directive, i.e. vi /usr/foo.txt However, this will not open foo.txt, vi creates a new file in the current directory instead. I can cd to the /usr directory and open the file with vi usr.txt. I'm using vi as an example, I'm actually trying to compile files with a gcc variant, and it can't access files the the / path either. You have a whole mess of non-Cygwin programs in your path. In the case of vi, you're using: Found: c:\WATCOM\BINNT\vi.exe Not Found: vim Cygwin POSIX paths only work in Cygwin programs. You can't expect some Watcom version of vi to know anything about them. If you want to use vi in Cygwin, install the Cygwin version (vim package.) And likewise with gcc, you don't have a Cygwin version of gcc installed. This means you won't be able to use POSIX paths, and you won't be compiling Cygwin binaries. If you want consistency in your command line tools you really need to clean up your PATH. For one thing it looks like it contains invalid characters: C D:\cygwin_root\Program Files\AMD\CodeAnalyst\bin C D:\cygwin_root\Program Files\AMD\CodeAnalyst\ This usually happens when you have typos like C;D:\foo. You need to fix those, but in general you need to remove a bunch of the crap you have in there, or otherwise realize that when invoking a non-Cygwin binary you can't use Cygwin features such as POSIX paths. Or use cygpath to convert between them. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] 1.5.24 unable to access files via root / (forward slash)
You have a whole mess of non-Cygwin programs in your path. Ah... it looks like I have a lot of housekeeping to take care of that I didn't know about. I need to do some reading up on the PATH variable, I thought it was only the stuff in /usr/etc/profile that set the PATH. Thanks! Jeff. -- View this message in context: http://www.nabble.com/1.5.24-unable-to-access-files-via-root---%28forward-slash%29-tf3260586.html#a9062765 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] 1.5.24 unable to access files via root / (forward slash)
Just to conclude my query, in the file usr/etc/profile I've added the line: PATH= Above my other PATH variables. When I run cygcheck again, all of the pre-existing Windows Path environment variables have gone, which seems to be what I needed to happen. Thanks to all, Jeff. -- View this message in context: http://www.nabble.com/1.5.24-unable-to-access-files-via-root---%28forward-slash%29-tf3260586.html#a9063791 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem installing cygwin+sshd
Michael wrote: Hello, I'm trying to install cygwin+sshd on a WinXPPro-machine, but get an error, when starting the service. It would be great, if someone is able to help me find a hint for a solution for this problem! Here a summary what I did: - logged in with domain-user with local admin privileges - installed cygwin - - to c:\cygwin - - for all users - - with packages openssh v4.5p1-1, tcp_wrappers v7.6-1 - added env-var CYGWIN and added cygwin-dir to PATH - started cygwin and ssh-host-config - - privilege separation - yes - - create local user sshd - yes - - install sshd as a service - yes - net start sshd = --cut-- $ net start sshd The CYGWIN sshd service is starting. The CYGWIN sshd service could not be started. The service did not report an error. More help is available by typing NET HELPMSG 3534. --cut-- - cygrunsrv --start sshd = --cut-- $ cygrunsrv --start sshd cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: The service has not been started. --cut-- other infos: ### eventvwr: --cut-- Die Beschreibung der Ereigniskennung ( 0 ) in ( sshd ) wurde nicht gefunden. Der lokale Computer verfügt nicht über die zum Anzeigen der Meldungen von einem Remotecomputer erforderlichen Registrierungsinformationen oder DLL-Meldungsdateien. Möglicherweise müssen Sie das Flag /AUXSOURCE= zum Ermitteln der Beschreibung verwenden. Weitere Informationen stehen in Hilfe und Support. Ereignisinformationen: sshd: PID 3940: `sshd' service stopped, exit status: 255. --cut-- ### no /var/log/ssh* files (???) ### file-permissions in /etc: ls -l /etc/ssh* -rwxr-x--- 1 SYSTEM mkgroup-l-d 1418 Feb 15 03:02 ssh_config -rw--- 1 SYSTEM mkgroup-l-d 672 Feb 15 03:02 ssh_host_dsa_key -rw-r--r-- 1 SYSTEM mkgroup-l-d 611 Feb 15 03:02 ssh_host_dsa_key.pub -rw--- 1 SYSTEM mkgroup-l-d 984 Feb 15 03:02 ssh_host_key -rw-r--r-- 1 SYSTEM mkgroup-l-d 648 Feb 15 03:02 ssh_host_key.pub -rw--- 1 SYSTEM mkgroup-l-d 1675 Feb 15 03:02 ssh_host_rsa_key -rw-r--r-- 1 SYSTEM mkgroup-l-d 403 Feb 15 03:02 ssh_host_rsa_key.pub -rw-r--r-- 1 SYSTEM mkgroup-l-d 3039 Feb 15 03:02 sshd_config ### I also changed the dir-permissions of c:\cygwin, c:\cygwin\var and c:\cygwin\var\log for user SYSTEM manually ### what else can I check??? any ideas? thank you very much for any help! br mik If all you want is an ssh server running under cygwin check out CopSSH. It might be easier to get running. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FW: Re: [EMAIL PROTECTED]: ***MEMORY-ERROR***: emacs[5172]: GSlice: failed
Jan Djärv wrote: Christopher Faylor wrote: Thanks much for the details. We do want to make things work correctly but, if that just means some work in emacs source code, then someone who is familiar with emacs will have to do that, i.e., someone else will have to come up with the config.h. OTOH, if someone could debug exactly why the error was occurring from one of the above calls then maybe we could make cygwin work better, too. Again, this requires someone who has access to emacs source and (presumably) knows how to use a debugger. I got W32 and cygwin up on a (not so fast) spare box, so I'm looking in to it now. memalign is definitely the function failing, but something more is going on here, I can't yet reduce this to a more simple case. Will keep trying though. It seems that when Emacs defines its own malloc and friends, memalign returns ENOSYS. But emacs defines its own memalign as well. Shouldn't that one be called? Jan D. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] 1.5.24 unable to access files via root / (forward slash)
* Jeff2007 (Tue, 20 Feb 2007 07:22:54 -0800 (PST)) Just to conclude my query, in the file usr/etc/profile I've added the line: PATH= Above my other PATH variables. When I run cygcheck again, all of the pre-existing Windows Path environment variables have gone, which seems to be what I needed to happen. No. You were advised to clean up your Windows paths - which are a mess. You've just cleaned up by putting the dirt under the carpet. Do not modify /etc/profile unless you know what you're doing. In this case it's obvious you're not. Thorsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24 unable to access files via root / (forward slash)
On 2/20/07, Jeff2007 wrote: Hi, I'm trying to access files for reading via the / directive, i.e. vi /usr/foo.txt However, this will not open foo.txt, vi creates a new file in the current directory instead. I can cd to the /usr directory and open the file with vi usr.txt. I'm using vi as an example, I'm actually trying to compile files with a gcc variant, and it can't access files the the / path either. I've checked with the mount command that / is mounted, and it reports: D:\cygwin_root on / type system (binmode) Output from ls -lg /usr shows -rwxrwxrwx 1 mkgroup-l-d 13 Feb 20 13:33 foo.txt Which seems ok from what I've read? I've attached the output from cygcheck using cygcheck -srvv. Apologies if I'm missing something really simple here. http://www.nabble.com/file/6655/cygcheck.out cygcheck.out Thanks in advance, Jeff. -- Jeff, mkgroup-l-d means that Cygwin doesn't know what group you are in. I believe when you run bash for the first time, you should see something like this: Your group name is currently mkgroup_l_d. This indicates that not all domain users and groups are listed in the /etc/passwd and /etc/group files. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l -d /etc/passwd mkgroup -l -d /etc/group This message is only displayed once (unless you recreate /etc/group) and can be safely ignored. Following that advice won't fix your path problems, but it is probably something you should remedy as it could lead to problems or confusion in the future. -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24 unable to access files via root / (forward slash)
On 2/20/07, Jeff2007 wrote: Hi, I'm trying to access files for reading via the / directive, i.e. vi /usr/foo.txt However, this will not open foo.txt, vi creates a new file in the current directory instead. I can cd to the /usr directory and open the file with vi usr.txt. I'm using vi as an example, I'm actually trying to compile files with a gcc variant, and it can't access files the the / path either. I've checked with the mount command that / is mounted, and it reports: D:\cygwin_root on / type system (binmode) Output from ls -lg /usr shows -rwxrwxrwx 1 mkgroup-l-d 13 Feb 20 13:33 foo.txt Which seems ok from what I've read? I've attached the output from cygcheck using cygcheck -srvv. Apologies if I'm missing something really simple here. http://www.nabble.com/file/6655/cygcheck.out cygcheck.out Thanks in advance, Jeff. -- Jeff, mkgroup-l-d means that Cygwin doesn't know what group you are in. I believe when you run bash for the first time, you should see something like this: Your group name is currently mkgroup_l_d. This indicates that not all domain users and groups are listed in the /etc/passwd and /etc/group files. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l -d /etc/passwd mkgroup -l -d /etc/group This message is only displayed once (unless you recreate /etc/group) and can be safely ignored. Following that advice won't fix your path problems, but it is probably something you should remedy as it could lead to problems or confusion in the future. -Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
CreateFile() and fopen issues on vista
Hi, I am trying to port a program from Windows XP to Vista and am running into several issues. 1) When I issue an fopen of a file with rb or wb modes they fails. I have since switched to just a r and w and it now works. This was not an issue on XP. 2) When I issue a CreateFile() function call against f: which is a USB drive an invalid handle error is returned. I would appreciate any help solving this. Some of the things that I have done are. a) Ran as the admin user b) created a manifest file to run the process as admin c) Ran CreateFile() on a directory (f://test) and not the root for the USB drive (f:) d) Turned off UAC Kirk Kirk Russell IT BJU 864 242 5100 x3884 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ls output still truncated
Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FW: Re: [EMAIL PROTECTED]: ***MEMORY-ERROR***: emacs[5172]: GSlice: failed
Jan D. wrote: Jan Djärv wrote: Christopher Faylor wrote: Thanks much for the details. We do want to make things work correctly but, if that just means some work in emacs source code, then someone who is familiar with emacs will have to do that, i.e., someone else will have to come up with the config.h. OTOH, if someone could debug exactly why the error was occurring from one of the above calls then maybe we could make cygwin work better, too. Again, this requires someone who has access to emacs source and (presumably) knows how to use a debugger. I got W32 and cygwin up on a (not so fast) spare box, so I'm looking in to it now. memalign is definitely the function failing, but something more is going on here, I can't yet reduce this to a more simple case. Will keep trying though. It seems that when Emacs defines its own malloc and friends, memalign returns ENOSYS. But emacs defines its own memalign as well. Shouldn't that one be called? Seems like it though it sounds like something that would be controlled by the emacs configure script to me. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Folks I could really use some help here. I still cannot get the ls command to work reliably. Well, I ran sum -r (I'm running cygwin 1.5.24): ~$ sum -r /bin/ls.exe /bin/cygwin1.dll 0875696 /bin/ls.exe 59473 1830 /bin/cygwin1.dll You might do the same and see if there is perhaps a different ls being run. You could also try fully qualifying the path to ls: /bin/ls --color=none /bin A portion of my cygcheck -svr shows: Cygwin DLL version info: DLL version: 1.5.24 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 156 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Wed Jan 31 10:57:51 CET 2007 CVS tag: cr-0x5f1 Shared id: cygwin1S4 I would wager that something is really hosed on your system, since none of the rest of us seem to have this problem. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Ken Shaffer wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. Well, I ran sum -r (I'm running cygwin 1.5.24): ~$ sum -r /bin/ls.exe /bin/cygwin1.dll 0875696 /bin/ls.exe 59473 1830 /bin/cygwin1.dll You might do the same and see if there is perhaps a different ls being run. You could also try fully qualifying the path to ls: /bin/ls --color=none /bin A portion of my cygcheck -svr shows: Cygwin DLL version info: DLL version: 1.5.24 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 156 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Wed Jan 31 10:57:51 CET 2007 CVS tag: cr-0x5f1 Shared id: cygwin1S4 I would wager that something is really hosed on your system, since none of the rest of us seem to have this problem. Ken I would think is something were really hosed, I've be having other problems, but I'm not. The only thing that isn't working - windows or cygwin - is ls.exe. My sum -r output, and the portion of the output from cygcheck -svr on my box are 100% identical to yours. Other than removing the ls.exe binary and converting it to a symlink for dir, I don't know what to do. Can you please check these md5sum's for me? $ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe 60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Can you please check these md5sum's for me? $ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe 60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe Same. ~$ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe 60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Can you trim it down to a simple directory with a file or two? If not, can you determine what is key to making it happen? You may have mentioned these before but I don't recall and didn't see them in my review of the thread: - Do you see this when running locally? From ssh? - Does it reproduce in bash? In bash run from cmd.exe? - Is CYGWIN environment variable still unset? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Managed mounts fail to support some legal POSIX filenames
While poking around with managed mounts following yesterday's mail, it occured to me that the managed-mount filename munging misses some cases, namely, filenames with trailing spaces, and filenames that look like Windows short-form names corresponding to existing file names. Here's an example: $ mkdir managed $ mount -o managed `cygpath -aw managed` $PWD/managed $ cd managed $ touch foo 'foo ' $ ls -l total 0 -rw-r--r-- 1 Jonathan None 0 Feb 20 13:48 foo $ rm foo $ touch longfilename.c longfi~1.c $ ls -l total 0 -rw-r--r-- 1 Jonathan None 0 Feb 20 13:48 longfilename.c $ rm longfilename.c $ cd .. $ umount `cygpath -aw managed` $ rm -r managed Fixing the first of these should be easy; space just needs to be handled the same as dot in fnmunge, and because of the bug existing managed mounts can't have files with trailing spaces. The second problem is trickier, since you'd want to keep compatibility with filenames containing tildes on existing managed mounts. -- Jonathan Lennox lennox at cs dot columbia dot edu -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CreateFile() and fopen issues on vista
Folks, Never mind. I went through and changed the permissions on the f: drive and now it is working again. Even though my userId in cygwin is administrator Windows does not seem to recognise me as such. CreateFile() is now able to create a valid handle once more. I also dont seem to have any side effects of changing the mode on the file. Kirk Kirk Russell IT BJU 864 242 5100 x3884 Kirk Russell [EMAIL PROTECTED] 2/20/2007 1:18:03 PM Hi, I am trying to port a program from Windows XP to Vista and am running into several issues. 1) When I issue an fopen of a file with rb or wb modes they fails. I have since switched to just a r and w and it now works. This was not an issue on XP. 2) When I issue a CreateFile() function call against f: which is a USB drive an invalid handle error is returned. I would appreciate any help solving this. Some of the things that I have done are. a) Ran as the admin user b) created a manifest file to run the process as admin c) Ran CreateFile() on a directory (f://test) and not the root for the USB drive (f:) d) Turned off UAC Kirk Kirk Russell IT BJU 864 242 5100 x3884 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Larry Hall (Cygwin) wrote: Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Can you trim it down to a simple directory with a file or two? If not, can you determine what is key to making it happen? You may have mentioned these before but I don't recall and didn't see them in my review of the thread: - Do you see this when running locally? From ssh? - Does it reproduce in bash? In bash run from cmd.exe? - Is CYGWIN environment variable still unset? Most of the info was in a thread from last week but in answer to the immediate questions... Nothing seems to be key to making it happen. It *usually* happens the first 3 or 4 times I try to ls a directory, then it works 90% of the time for that directory. The /cygdrive directory I see it running locally. Local is the only way I run. I do not have sshd installed. It reproduces in bash and pdksh whether I run from cmd.exe or xterm. If run from cmd.exe using the batch file, CYGWIN=tty. If run via an xterm it's not set. I can reproduce the problem even on a directory with only one file. Thanks for looking into this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Chuck wrote: Larry Hall (Cygwin) wrote: Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Can you trim it down to a simple directory with a file or two? If not, can you determine what is key to making it happen? You may have mentioned these before but I don't recall and didn't see them in my review of the thread: - Do you see this when running locally? From ssh? - Does it reproduce in bash? In bash run from cmd.exe? - Is CYGWIN environment variable still unset? Most of the info was in a thread from last week but in answer to the immediate questions... Nothing seems to be key to making it happen. It *usually* happens the first 3 or 4 times I try to ls a directory, then it works 90% of the time for that directory. The /cygdrive directory I see it running locally. Local is the only way I run. I do not have sshd installed. It reproduces in bash and pdksh whether I run from cmd.exe or xterm. If run from cmd.exe using the batch file, CYGWIN=tty. If run via an xterm it's not set. I can reproduce the problem even on a directory with only one file. Can you send the output of a successful 'ls -l' from within a directory with one file and then the strace of a failing case of 'ls' within this directory and a non-failing case of the same to the list? Does it work fine without 'tty' set for bash run at cmd.exe? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
On 2007-02-20, Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. At this point, I'd be inclined to get the source for ls, build a version with debugging enabled, and use gdb. I've never used gdb under Cygwin, so there may be some reason it isn't as useful under Cygwin as it is under, say, Linux. In that case, you could add a few printfs to see what's happening. Just my $0.02, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Gary Johnson wrote: On 2007-02-20, Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. At this point, I'd be inclined to get the source for ls, build a version with debugging enabled, and use gdb. I've never used gdb under Cygwin, so there may be some reason it isn't as useful under Cygwin as it is under, say, Linux. In that case, you could add a few printfs to see what's happening. There's no great difference between gdb on Cygwin vs Linux. Doing some debugging locally is by far the best way to gain some insight as to what's going on. Good advice. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Gary Johnson wrote: On 2007-02-20, Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. At this point, I'd be inclined to get the source for ls, build a version with debugging enabled, and use gdb. I've never used gdb under Cygwin, so there may be some reason it isn't as useful under Cygwin as it is under, say, Linux. In that case, you could add a few printfs to see what's happening. Just my $0.02, Gary I haven't done this sort of thing in about 10 years, but that was actually my next thought too. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Larry Hall (Cygwin) wrote: Chuck wrote: Larry Hall (Cygwin) wrote: Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Can you trim it down to a simple directory with a file or two? If not, can you determine what is key to making it happen? You may have mentioned these before but I don't recall and didn't see them in my review of the thread: - Do you see this when running locally? From ssh? - Does it reproduce in bash? In bash run from cmd.exe? - Is CYGWIN environment variable still unset? Most of the info was in a thread from last week but in answer to the immediate questions... Nothing seems to be key to making it happen. It *usually* happens the first 3 or 4 times I try to ls a directory, then it works 90% of the time for that directory. The /cygdrive directory I see it running locally. Local is the only way I run. I do not have sshd installed. It reproduces in bash and pdksh whether I run from cmd.exe or xterm. If run from cmd.exe using the batch file, CYGWIN=tty. If run via an xterm it's not set. I can reproduce the problem even on a directory with only one file. Can you send the output of a successful 'ls -l' from within a directory with one file and then the strace of a failing case of 'ls' within this directory and a non-failing case of the same to the list? Does it work fine without 'tty' set for bash run at cmd.exe? Your wish is my command. Attached are two strace output files. The names should be self-explanatory. Please let me know if you see anything. In the mean time I'm going to refresh myself on the use of gcc and gdb and see if I can trace the execution of ls. Like I said in another post though, it's been a *very* long time since I've done any C programming and I don't think I've ever used the gnu debugger. ** Program name: C:\cygwin\bin\ls.exe (pid 1036, ppid 1) App version: 1005.23, api: 0.156 DLL version: 1005.24, api: 0.156 DLL build:2007-01-31 10:57 OS version: Windows NT-5.1 Heap size:402653184 Date/Time:2007-02-20 15:55:08 ** 66 645 [main] ls 1036 set_myself: myself-dwProcessId 1036 64 709 [main] ls 1036 time: 1172004908 = time (0) 16692378 [main] ls 1036 environ_init: GetEnvironmentStrings returned 0x2452C0 - ALLUSERSPROFILE=C:\Documents and Settings\All Users 1262504 [main] ls 1036 environ_init: 0x670238: ALLUSERSPROFILE=C:\Documents and Settings\All Users 1002604 [main] ls 1036 environ_init: 0x670270: APPDATA=C:\Documents and Settings\CHamilto\Application Data 2192823 [main] ls 1036 environ_init: 0x6702B0: CLASSPATH=.;C:\Program Files\Java\jre1.5.0_09\lib\ext\QTJava.zip 1012924 [main] ls 1036 environ_init: 0x6702F8: CLIENTNAME=Console 973021 [main] ls 1036 environ_init: 0x670310: COMMONPROGRAMFILES=C:\Program Files\Common Files 983119 [main] ls 1036 environ_init: 0x670348: COMPUTERNAME=CHAMILTON-DEL 973216 [main] ls 1036 environ_init: 0x670368: COMSPEC=C:\WINDOWS\system32\cmd.exe 963312 [main] ls 1036 environ_init: 0x670390: CVSROOT=c:\program files\PuTTY 983410 [main] ls 1036 environ_init: 0x6703B8: CVS_RSH=/bin/ssh 953505 [main] ls 1036 environ_init: 0x6703D0: DISPLAY=127.0.0.1:0.0 963601 [main] ls 1036 environ_init: 0x6703F0: FP_NO_HOST_CHECK=NO 1023703 [main] ls 1036 getwinenv: can't set native for HOME= since no environ yet 1063809 [main] ls 1036 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\CHamilto, no-keep-rel, no-add-slash) 653874 [main] ls 1036 normalize_win32_path: C:\cygwin\home\CHamilto = normalize_win32_path (C:\cygwin\home\CHamilto) 683942 [main] ls 1036 mount_info::conv_to_posix_path: /home/CHamilto = conv_to_posix_path (C:\cygwin\home\CHamilto) 1404082 [main] ls 1036 win_env::add_cache: posix /home/CHamilto 564138 [main] ls 1036 win_env::add_cache: native HOME=C:\cygwin\home\CHamilto 584196 [main] ls 1036 posify: env var converted to HOME=/home/CHamilto 964292 [main] ls 1036 environ_init: 0x670430: HOME=/home/CHamilto 974389 [main] ls 1036 environ_init: 0x670408: HOMEDRIVE=C:
Re: ls output still truncated
On 2/20/07, Chuck wrote: Your wish is my command. Attached are two strace output files. The names should be self-explanatory. Please let me know if you see anything. In the mean time I'm going to refresh myself on the use of gcc and gdb and see if I can trace the execution of ls. Like I said in another post though, it's been a *very* long time since I've done any C programming and I don't think I've ever used the gnu debugger. SNIP TRACE DATA I'm using gmail and the traces are embedded in the email, so forgive me if I'm way off base. If these are the full traces, then when it works ls runs fine. When it doesn't work ls was killed somehow. In the first trace file the last line is: 62 11096 [main] ls 1036 normalize_win32_path: c:\Program Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program Files\QuickTime\QTSystem\) Notice that ls never performed a closedir or wrote any data out. The last trace file shows: 167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60) 178 42094 [main] ls 3048 closedir: 0 = closedir (0xA) 113 42207 [main] ls 3048 fhandler_base::fstat: here 59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20) 372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1 65 42703 [main] ls 3048 sig_send: wakeup 0x6C8 68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8 66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8 72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34 105 43014 [main] ls 3048 fhandler_base::write: binary write Which got to the point where ls closed the dir handle and actually wrote some data. I don't know what would kill a process like that? Or am I just not seeing all of the data? -- Frodak -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
On 02/20/2007, Chuck wrote:
Larry Hall (Cygwin) wrote:
Can you send the output of a successful 'ls -l' from within a directory
with one file and then the strace of a failing case of 'ls' within this
directory and a non-failing case of the same to the list?
Does it work fine without 'tty' set for bash run at cmd.exe?
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory.
What is the path to this directory? What's the listing ('ls -l') of this
directory? What's the difference, if any, when 'ls' is run in this
directory without 'tty' set in the CYGWIN environment variable (this needs
to *not* be set at shell start-up time)?
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
_
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Frodak Baksik wrote: On 2/20/07, Chuck wrote: Your wish is my command. Attached are two strace output files. The names should be self-explanatory. Please let me know if you see anything. In the mean time I'm going to refresh myself on the use of gcc and gdb and see if I can trace the execution of ls. Like I said in another post though, it's been a *very* long time since I've done any C programming and I don't think I've ever used the gnu debugger. SNIP TRACE DATA I'm using gmail and the traces are embedded in the email, so forgive me if I'm way off base. If these are the full traces, then when it works ls runs fine. When it doesn't work ls was killed somehow. In the first trace file the last line is: 62 11096 [main] ls 1036 normalize_win32_path: c:\Program Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program Files\QuickTime\QTSystem\) Notice that ls never performed a closedir or wrote any data out. The last trace file shows: 167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60) 178 42094 [main] ls 3048 closedir: 0 = closedir (0xA) 113 42207 [main] ls 3048 fhandler_base::fstat: here 59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20) 372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1 65 42703 [main] ls 3048 sig_send: wakeup 0x6C8 68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8 66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8 72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34 105 43014 [main] ls 3048 fhandler_base::write: binary write Which got to the point where ls closed the dir handle and actually wrote some data. I don't know what would kill a process like that? Or am I just not seeing all of the data? -- Frodak I think it's actually something to do with the gmane interface that I post to. I attach the files with Thunderbird but when they post to the list, they end up being embedded. Apologies but there doesn't seem to be any way for me to control that. You are seeing things correctly. This has been the problem all along. When ls fails, it just dies right in the middle, but exits with a 0 error code. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Frodak Baksik wrote: On 2/20/07, Chuck wrote: Your wish is my command. Attached are two strace output files. The names should be self-explanatory. Please let me know if you see anything. In the mean time I'm going to refresh myself on the use of gcc and gdb and see if I can trace the execution of ls. Like I said in another post though, it's been a *very* long time since I've done any C programming and I don't think I've ever used the gnu debugger. SNIP TRACE DATA I'm using gmail and the traces are embedded in the email, so forgive me if I'm way off base. If these are the full traces, then when it works ls runs fine. When it doesn't work ls was killed somehow. In the first trace file the last line is: 62 11096 [main] ls 1036 normalize_win32_path: c:\Program Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program Files\QuickTime\QTSystem\) Notice that ls never performed a closedir or wrote any data out. The last trace file shows: 167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60) 178 42094 [main] ls 3048 closedir: 0 = closedir (0xA) 113 42207 [main] ls 3048 fhandler_base::fstat: here 59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20) 372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1 65 42703 [main] ls 3048 sig_send: wakeup 0x6C8 68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8 66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8 72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34 105 43014 [main] ls 3048 fhandler_base::write: binary write Which got to the point where ls closed the dir handle and actually wrote some data. I don't know what would kill a process like that? Or am I just not seeing all of the data? No, you're seeing all the data sent. Chuck, what's the error code returned from each case? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Larry Hall (Cygwin) wrote: Frodak Baksik wrote: On 2/20/07, Chuck wrote: Your wish is my command. Attached are two strace output files. The names should be self-explanatory. Please let me know if you see anything. In the mean time I'm going to refresh myself on the use of gcc and gdb and see if I can trace the execution of ls. Like I said in another post though, it's been a *very* long time since I've done any C programming and I don't think I've ever used the gnu debugger. SNIP TRACE DATA I'm using gmail and the traces are embedded in the email, so forgive me if I'm way off base. If these are the full traces, then when it works ls runs fine. When it doesn't work ls was killed somehow. In the first trace file the last line is: 62 11096 [main] ls 1036 normalize_win32_path: c:\Program Files\QuickTime\QTSystem\ = normalize_win32_path (c:\Program Files\QuickTime\QTSystem\) Notice that ls never performed a closedir or wrote any data out. The last trace file shows: 167 41916 [main] ls 3048 fhandler_disk_file::closedir: 0 = closedir (0x6A1A60) 178 42094 [main] ls 3048 closedir: 0 = closedir (0xA) 113 42207 [main] ls 3048 fhandler_base::fstat: here 59 42266 [main] ls 3048 fstat64: 0 = fstat (1, 0x22BA20) 372 42638 [main] ls 3048 sig_send: sendsig 0x6FC, pid 3048, signal -34, its_me 1 65 42703 [main] ls 3048 sig_send: wakeup 0x6C8 68 42771 [main] ls 3048 sig_send: Waiting for pack.wakeup 0x6C8 66 42837 [sig] ls 3048 wait_sig: signalling pack.wakeup 0x6C8 72 42909 [main] ls 3048 sig_send: returning 0x0 from sending signal -34 105 43014 [main] ls 3048 fhandler_base::write: binary write Which got to the point where ls closed the dir handle and actually wrote some data. I don't know what would kill a process like that? Or am I just not seeing all of the data? No, you're seeing all the data sent. Chuck, what's the error code returned from each case? Error code in both cases is 0. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
g++ 3.4.4: all global constructors in archive not called
Dear cygwin readers,
I have just ported an application from Linux to Cygwin.
In one archive (.a) I have several global constructors,
2-3 in two .o files. When I run my program only one
initializer function is called in that archive. Leaving
the other uninitialized/uncalled.
I have found this issue reported in 2002, but there
is no solutions posted in response to this question.
http://sourceware.org/ml/cygwin/2002-07/msg00447.html
To verify this problem I created a simple class and made
a local global instance. The class name and output string
was slightly different in the other file.
class a_very_local_t {
public:
a_very_local_t() {
printf(arbfragprog.cc: very_local_t::constructor\n);
_info = 0;
}
private:
int _info;
};
static a_very_local_t a_local_instance_a;
When the program is started I only get the output from
one of the .o files (the first alphabetically).
It appears to me a rather fundamental issue that should have
been solved years ago. Have I missed to provide the
compiler/linker/archiver with an appropriate flag?
Thanks in advance for your help.
best regards / Patric
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Chuck wrote: I think it's actually something to do with the gmane interface that I post to. I attach the files with Thunderbird but when they post to the list, they end up being embedded. Apologies but there doesn't seem to be any way for me to control that. No, it's working right... your files are attached with whatever MIME type causes them to be 'previewed', which is The Right Way according to past discussion. -- Matthew Do you do windows as well? Only when I'm forced to deal with Microsoft... -- from a story by Feech -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Interesting fact that dir.exe works and ls.exe does not. Inspecting the source, the one and only difference between the two is: -- ls-ls.c begin -- #include ls.h int ls_mode = LS_LS; -- ls-ls.c end -- -- ls-dir.c begin -- #include ls.h int ls_mode = LS_MULTI_COL; -- ls-dir.c end -- For all purposes, they should behave exactly the same, except for the output format. It's a shot in the dark, but could you try: 1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails? 2) Does ls -l also fails? 3) Does vdir.exe fails? Do you have antivirus or webcam software running? They are known for causing random problems in Cygwin apps. Cesar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Larry Hall (Cygwin) wrote:
On 02/20/2007, Chuck wrote:
Larry Hall (Cygwin) wrote:
Can you send the output of a successful 'ls -l' from within a directory
with one file and then the strace of a failing case of 'ls' within this
directory and a non-failing case of the same to the list?
Does it work fine without 'tty' set for bash run at cmd.exe?
Your wish is my command. Attached are two strace output files. The names
should be self-explanatory.
What is the path to this directory? What's the listing ('ls -l') of this
directory? What's the difference, if any, when 'ls' is run in this
directory without 'tty' set in the CYGWIN environment variable (this needs
to *not* be set at shell start-up time)?
The path to the directory is /cygwin/home/CHamilto/test. The ls -l
listing (when it works) is...
$ ls -l
total 49120
drwxr-xr-x+ 2 CHamilto Domain Users0 Feb 20 15:54 ./
drwxr-xr-x+ 18 CHamilto Domain Users0 Feb 20 15:54 ../
-rwxr-xr-x 1 CHamilto Domain Users 50297564 Feb 20 12:22 test.wav*
$ pwd
/home/CHamilto/test
CYGWIN was not set when I ran it as you can see below.
$ set | grep CYGWIN
$
I downloaded the source for coreutils and see that in ls.c the same
source code is used to compile ls, dir, and vdir. The strange thing is
that dir and vdir never fail. Only ls does. I haven't figured out how to
compile with the debugging info yet.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: CreateFile() and fopen issues on vista
2) When I issue a CreateFile() function call against f: which is a USB drive an invalid handle error is returned. In general, it is a bad idea to mix Windows APIs with cygwin, since you are going behind cygwin's back, and can no longer guarantee cygwin's POSIX-y behavior. Using CreateFile from a cygwin program is asking for problems. Use fopen() or open() instead. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Can you please check these md5sum's for me? $ md5sum /bin/ls.exe /usr/bin/ls.exe /usr/bin/dir.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */bin/ls.exe 64e3dc0e3a5ef0eeeaa4f2e9b984844d */usr/bin/ls.exe 60a0c7768052ec4306c3e0f680331afa */usr/bin/dir.exe /bin and /usr/bin are typically the same directory (accessed via separate mount points) unless you have altered the default mounts. And ls vs. dir are both built from the same source files in coreutils; the difference is that ls has a different set of builtin defaults than dir. As for why your output is getting truncated, I have no idea. -- Eric Blake volunteer cygwin coreutils maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Sony Dual [CD/DVD] RW Drive Problems
I have one of those IEEE 1394 (Firewire) CD/DVD-RW+RW drives.
When I recursively copy one directory ('x.ab') from my HDD to a DVD-RW
in Explorer, everything looks good until I do an 'ls -l' on the drive.
Then I see in the 'ls -l' output listing many copies of the directory as
some kind of a binary (?) file. E.g.,
br---T 9281 Everyone root 22, 34090 Jan 14 1979 x.ab
br---T 9281 Everyone root 22, 34090 Jan 14 1979 x.ab
br---T 9281 Everyone root 22, 34090 Jan 14 1979 x.ab
...
.
.
.
Note that while I can 'cd' into the child directories of 'x.ab', I get
the same problem in each of them, namely repeated listing of all subdirs
as binary files.
The files in the directory are fine on the Sony drive as long as I
access them via Explorer or simple bash single file commands.
Also, I get error messages when I try to use either chmod or 'chown' on
the dir or subdirs.
The drive uses Ahead Nero InCD which formats on the fly. Moreover, I
can't use 'format' from either a cmd.exe (or bash) prompt, or an
explorer Properties / Tools menu.
This makes the drive useless for the backup and archive scripts I've
developed with Cygwin.
Anybody (a) know what's going on here, (b) how I can resolve this at
zero cost, or (c) how I can resolve this at any cost (not including
buying a new DVD-RW drive, or running GNU-Linux or -BSD! ;-))?
Thanks,
Lee Rothstein
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: g++ 3.4.4: all global constructors in archive not called
Patric Ljung plg at itn.liu.se writes: Dear cygwin readers, I have just ported an application from Linux to Cygwin. In one archive (.a) I have several global constructors, 2-3 in two .o files. When I run my program only one initializer function is called in that archive. Leaving the other uninitialized/uncalled. I don't believe this is a cygwin issue, but in any case... linking to an archive file is not the same thing as linking to all the .o files it contains. When you link to an archive file, the linker only pulls in those object files that contain symbols it needs for the link. This is so you can link to a large archive without worrying that code irrelevant to your project will be linked as well. The linker won't include a .o file simply because that file has local static objects with constructors that need to be called. You have to redesign the source structure to enforce that that .o file needs to be included for another reason, or explicitly include it in the build (as opposed to having it be part of an archive). If an .o file is never used, the linker assumes you don't care about the side effects of any objects created in that file. If your linker on a different platform behaves differently, I find that surprising, but perhaps it is allowed. -Lewis -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Cesar Strauss wrote: Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Interesting fact that dir.exe works and ls.exe does not. Inspecting the source, the one and only difference between the two is: -- ls-ls.c begin -- #include ls.h int ls_mode = LS_LS; -- ls-ls.c end -- -- ls-dir.c begin -- #include ls.h int ls_mode = LS_MULTI_COL; -- ls-dir.c end -- For all purposes, they should behave exactly the same, except for the output format. It's a shot in the dark, but could you try: 1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails? 2) Does ls -l also fails? 3) Does vdir.exe fails? Do you have antivirus or webcam software running? They are known for causing random problems in Cygwin apps. Cesar No webcam software. I have av software but it's the same av software that's been running for 2 years and never caused a problem before - Symantec 10.0.2.2002. I can't remove it. It's a corporate PC and it's against corporate policy to remove it. I created myls as you said and can not get it to fail. You may be on to something! I just ran myls 30 times in a row on the one directory that ls chokes on most often - /cygdrive. It didn't fail once. Ls on the other hand fails almost 50% of the time. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
On 02/20/2007, Chuck wrote: I downloaded the source for coreutils and see that in ls.c the same source code is used to compile ls, dir, and vdir. The strange thing is that dir and vdir never fail. Only ls does. I haven't figured out how to compile with the debugging info yet. make CFLAGS=-g -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls output still truncated
Chuck wrote: Cesar Strauss wrote: Chuck wrote: Folks I could really use some help here. I still cannot get the ls command to work reliably. It worked for years and about two weeks ago started sputtering. I have completely unstalled all cygwin packages, deleted the directories, and reinstalled from scratch. Even just installing the bare mimimum packages and running a bash shell without X or even a .profile, ls still fails to output anything 50% of the time. One other observation I've made is there's a similar program named dir.exe in the /usr/bin directory. It seems to do pretty much the same thing as ls. In fact the file sizes and timestamps are even the same. It works every time. I could just alias ls=/usr/bin/dir but that seems more like a work-around rather than fixing the real problem. Can anyone help with this? TIA Interesting fact that dir.exe works and ls.exe does not. Inspecting the source, the one and only difference between the two is: -- ls-ls.c begin -- #include ls.h int ls_mode = LS_LS; -- ls-ls.c end -- -- ls-dir.c begin -- #include ls.h int ls_mode = LS_MULTI_COL; -- ls-dir.c end -- For all purposes, they should behave exactly the same, except for the output format. It's a shot in the dark, but could you try: 1) Copy ls.exe to myls.exe and run it as myls.exe. Does it still fails? 2) Does ls -l also fails? 3) Does vdir.exe fails? Do you have antivirus or webcam software running? They are known for causing random problems in Cygwin apps. Cesar No webcam software. I have av software but it's the same av software that's been running for 2 years and never caused a problem before - Symantec 10.0.2.2002. I can't remove it. It's a corporate PC and it's against corporate policy to remove it. I created myls as you said and can not get it to fail. You may be on to something! I just ran myls 30 times in a row on the one directory that ls chokes on most often - /cygdrive. It didn't fail once. Ls on the other hand fails almost 50% of the time. The only pattern I can see, strange as it may be, is that somehow any process whose name is ls.exe is being killed randomly in your system. Try this: 1) Copy dir.exe to ls.exe 2) Copy du.exe to ls.exe 3) Copy myls.exe to /tmp/ls.exe Does the newly copied ls.exe fails in each case? Cesar -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: g++ 3.4.4: all global constructors in archive not called
Lewis Hyatt wrote: Patric Ljung plg at itn.liu.se writes: I have just ported an application from Linux to Cygwin. In one archive (.a) I have several global constructors, 2-3 in two .o files. When I run my program only one initializer function is called in that archive. Leaving the other uninitialized/uncalled. I don't believe this is a cygwin issue, but in any case... linking to an archive file is not the same thing as linking to all the .o files it contains. When you link to an archive file, the linker only pulls in those object files that contain symbols it needs for the link. This is so you can link to a large archive without worrying that code irrelevant to your project will be linked as well. The linker won't include a .o file simply because that file has local static objects with constructors that need to be called. You have to redesign the source structure to enforce that that .o file needs to be included for another reason, or explicitly include it in the build (as opposed to having it be part of an archive). Or, perhaps, try the --whole-archive linker option: gcc -o my_prog.exe my_prog.o -Wl,--whole-archive my_lib.a -Wl,--no-whole-archive other libs I don't know for sure if it will work, but it's worth a try. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
How do I launch an rxvt-unicode shell?
Hey, I recently installed rxvt-unicode. That much was easy. Could someone please tell me how to launch a shell? And just out of curiosity, what's the best shell option in cygwin if I want my Linux shell on Windows? Thanks, - GM -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How do I launch an rxvt-unicode shell?
Grok Mogger wrote: I recently installed rxvt-unicode. That much was easy. Could someone please tell me how to launch a shell? First of all, realize that the rxvt-unicode package is X11 only. So you need to run the X server first before launching urxvt. And also, despite its name, it does not support unicode, since Cygwin itself does not really support unicode. The rationale for all of this is explained in the release announcements, e.g. http://www.cygwin.com/ml/cygwin-announce/2006-05/msg4.html Now, if you don't want X11 then you can use the plain old 'rxvt' package. This one is dual-flavor: it uses windows native graphics (GDI) if no X server is running, or it does X11 if DISPLAY is set. This can be adventageous if you don't want the bloat of X just for some consoles. In general when launching any rxvt, you normally need to specify something with -e to execute. If you don't, you get just plain bash, not even bash --login, so your profile won't be read. Most people want bash --login --interactive so you should specify that. There are zillions of other options you can give to rxvt, just read the manpage. You can also use ~/.Xdefaults to make these settings so that you don't have to specify them on the command line every time. On the other hand, if you create a Windows shortcut to rxvt you can just stick them there and not worry about it. An example of the kind of thing I personally use is: rxvt -geometry 130x60 -bg black -fg gray -cr white -fn Lucida Console-11 -sr -sl 5000 -j -cr white -tn rxvt -e bash -li You might have to play with the various -tn settings. Good choices would be rxvt-cygwin (for when using X11 flavor) and rxvt-cygwin-native (for when using W11/GDI flavor.) And just out of curiosity, what's the best shell option in cygwin if I want my Linux shell on Windows? You seem to be confusing the concepts of a terminal and a shell. A terminal or console is the thing that displays characters, such as xterm, rxvt, etc. A shell is the program that interprets commands interactively, e.g. bash, zsh, ksh, etc. These are two totally unrelated things -- you can run shell scripts non-interactively with no terminal, and you can directly invoke binaries and view their output on a terminal without a shell. Cygwin ships with bash as the default shell, same as Linux, so there's nothing different there. The choices for terminal on Cygwin are approximately: - native Windows console - rxvt, GDI - rxvt, X11 - rxvtu, X11 - xterm, X11 (or any other X11 terminal that you compile yourself, really) - third party native, e.g. http://sourceforge.net/projects/console or putty. With putty there is also cygputty which is kind of a go-between that makes putty aware of Cygwin and eliminates some of the problems you have when using a native (non-Cygwin) program attached to a Cygwin tty. Personally, I use rxvt GDI. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
