Re: [ITP 1.7] dbus-glib
On Jun 23 23:56, Yaakov S wrote: dbus-glib provides a GObject interface for D-Bus. It is a prerequisite of the GNOME 2.26 libraries. Please note that this requires the Ports version of glib2, which is current (vs. the distro's) and has a new layout; all the GNOME 2.26 libraries will be updated simultaneously. So for testing purposes, you must use these: if I understand you correctly, this isn't only a requirement for the latest GNOME, it also won't work without the latest GNOME stuff. So I'd say, that's just one of the packages which constitute the GNOME update and you know how to do it. Just upload when you're finished. Other than that, I added these packages to the Cygwin package maintainance list at http://cygwin.com/cygwin-pkg-maint. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] task-1.7.1-1 (pinging for awaiting review)
I have now fixed the 2 remarks you had: 1) setup.hint ... 2) task-1.7.1-1.src.tar.bz2 ... So I would appreciate if you could take a new look at the new files at http://taskwarrior.org/download/cygwin/setup.hint http://taskwarrior.org/download/cygwin/task-1.7.1-1-src.tar.bz2 http://taskwarrior.org/download/cygwin/task-1.7.1-1.tar.bz2 Apart from the fixed packages of task fro cygwin-1.5 I have now also uploaded packages for cygwin-1.7. So you can find the packages for the review and upload under cygwin-1.5) http://taskwarrior.org/download/cygwin/setup.hint http://taskwarrior.org/download/cygwin/task-1.7.1-1-src.tar.bz2 http://taskwarrior.org/download/cygwin/task-1.7.1-1.tar.bz2 cygwin-1.7) http://taskwarrior.org/download/cygwin/1.7/setup.hint http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1-src.tar.bz2 http://taskwarrior.org/download/cygwin/1.7/task-1.7.1-1.tar.bz2 THX for your time and help. /Federico
Re: [ITP 1.7] dbus-glib
On 24/06/2009 03:11, Corinna Vinschen wrote: if I understand you correctly, this isn't only a requirement for the latest GNOME, it also won't work without the latest ... glib. So I'd say, that's just one of the packages which constitute the GNOME update and you know how to do it. Just upload when you're finished. Fine. Let me give you a headsup then, that among the GNOME libraries already in the distro, a few packages were split out into their own upstream tarballs: python-gobject2 from python-gtk2, and gnome-vfs2-monikers from gnome-vfs2. I will be adding these as well. Other than that, I added these packages to the Cygwin package maintainance list at http://cygwin.com/cygwin-pkg-maint. After I'm finished uploading, you'll want to rescan the packages in release-2/GNOME to get the current layout, as they have all been rearranged since way back when. (Of course, I will assure the upgrade is smooth, so there will be a number of _obsolete packages when I'm finished). Once that's done (probably next week), I will be ready to ITP some more GNOME libraries that have never been in the distro. Yaakov
[ANNOUNCEMENT] [1.7] Updated: xinit-1.1.1-3
The following package has been updated for Cygwin 1.7: * xinit-1.1.1-3 This releases fixes a few bugs reported to the list: * startxdmcp.bat script now accepts a hostname argument * Fix Start Menu shortcut where Cygwin is not installed in C: Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] [1.7] Updated: xinput-1.4.1-1
The following package has been updated for Cygwin 1.7: * xinput-1.4.1-1 This update corresponds to the XI changes in xorg-server-1.6, inputproto-1.5 and libXi-1.2. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] [1.7] Updated: xrandr-1.3.0-10
The following package has been updated for Cygwin 1.7: * xrandr-1.3.0-10 This update corresponds to the changes in the RandR extension in xorg-server-1.6 and randrproto/libXrandr-1.3. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] [1.7] Updated: xorg-server-1.6.0 and more
I have updated the Cygwin/X xorg-server to 1.6.0 for Cygwin 1.7. Please note the major upstream changes in this version: * XEvIE extension support has been removed. Therefore, libXevie and libxcb-xevie are deprecated and will soon be removed. * In windowed (desktop) mode, -br (black background with mouse cursor hidden until XDefineCursor() is first called) is now the default. The old behaviour can be obtained with the -retro flag. The following new patches have been applied to this release: * added Hebrew keyboard layout detection. * added more clipboard debugging messages. * fixed numeric keypad input. * reverted upstream clipboard change that wreaked havoc with other applications monitoring the clipboard (e.g. MS Office Clipboard, VNC). Together with a new release comes updates to some X.Org libraries: inputproto 1.5.1 libxcb 1.2 libICE 1.0.5 libX11 1.2 libXext 1.0.5 libXfont1.4.0 libXi 1.2.1 libXrandr 1.3.0 pixman 0.14.0 xcb-proto 1.4 xcb-util0.3.4 xextproto 7.0.5 xtrans 1.2.3 randrproto 1.3.0 The newest versions of libX11 and libxcb are required for xorg-server-1.6.0, and they must both be updated to 1.2 simultaneously. All other X.Org libraries, save those just deprecated, have been rebuilt for Cygwin 1.7 with gcc-4.3. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/
[ANNOUNCEMENT] [1.7] Updated: mkfontscale-1.0.6-10
The following package has been updated for Cygwin 1.7: * mkfontscale-1.0.6-10 This release adds support for bzip2-compressed fonts. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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/doc ChangeLog faq-setup.xml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-06-24 07:49:37 Modified files: winsup/doc : ChangeLog faq-setup.xml Log message: * faq-setup.xml (faq.setup.setup-fails-on-ts): Fix typo. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.213r2=1.214 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-setup.xml.diff?cvsroot=srcr1=1.16r2=1.17
src/winsup/doc ChangeLog faq-setup.xml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-06-24 07:57:03 Modified files: winsup/doc : ChangeLog faq-setup.xml Log message: * faq-setup.xml (faq.setup.setup-fails-on-ts): Fix another typo. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.214r2=1.215 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-setup.xml.diff?cvsroot=srcr1=1.17r2=1.18
src/winsup/w32api ChangeLog include/wtsapi32.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-06-24 10:30:07 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: wtsapi32.h Log message: * include/wtsapi32.h (WTSQueryUserToken, WTSEnumerateSessionsW, WTSEnumerateSessionsA): Add function prototypes. (struct _WTS_SESSION_INFOW, struct _WTS_SESSION_INFOA): Add typedefs. (WTS_SESSION_INFO, PWTS_SESSION_INFO, WTSEnumerateSessions): Add defines dependent on UNICODE setting. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.989r2=1.990 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/wtsapi32.h.diff?cvsroot=srcr1=1.4r2=1.5
Re: setup-1.7.exe command line options
2009/6/23 Christopher Faylor: On Tue, Jun 23, 2009 at 04:13:39PM -0500, Thrall, Bryan wrote: Where can I find documentation on the setup-1.7.exe command line options, in particular the one for installing packages without invoking the GUI that I think was added last year? I had a look in all the places I could think of, but without success, and invoking setup with -h, -H, -help or --help does nothing. I guess you are using an older setup-1.7.exe; When I type 'setup-1.7.exe -h', I get: $ setup-1.7.exe -h Starting cygwin install, version 2.629 Current Directory: E:\My Downloads Command Line Options: -D --download Download from internet -L --local-install Install from local directory -s --site Download site -R --root Root installation directory -P --packages Specify packages to install [snip] Older versions of setup just wrote this output to setup.log and setup.log.full in the directory where setup was run, but now it writes it to stdout, too :) Yep. I added this functionality recently. It may not work when dumping to the console since it relies on a Windows function call which isn't availabe on older versions of Windows. But this should work: setup-1.7 -h | cat (I recently got a cygwin crash doing something like this on Windows NT4. I plan to debug that crash this weekend) Also, running it from mintty or with CYGWIN=tty should work as well. I had actually downloaded the latest setup-1.7.exe, but I must have invoked the wrong one when I tried it. D'oh. The -P option is working nicely, especially when combined with -q for unattended install. Throw 'cygcheck -p' into the mix, and this should keep the apt-getters happy. Thanks to everyone involved! 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
Re: [ANNOUNCEMENT] Updated: bash-3.2.49-22
On Jun 23 20:14, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of bash, 3.2.49-22, has been uploaded, replacing 3.2.48-21 as current, and leaving 3.1-6 as previous. This is probably the last bash release for cygwin 1.5; my next release will be bash 4.0 for cygwin 1.7. NEWS: = This is a minor patch release, which incorporates 1 official upstream patch (actually, the patch is picked up by linking against readline-5.2.14-12). It also enables the tsaware peflag on the shell, to make it easier to complete postinstall scripts on Windows Server 2008. Just a minor note. Bash runs fine without the TS-aware flag on Windows Server 2008. Only servers which actually have the Terminal Service installed get this problem. I added a FAQ entry related to this problem to the new FAQ for Cygwin 1.7: http://cygwin.com/1.7/faq/faq.setup.html#faq.setup.setup-fails-on-ts 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
Re: [1.7] sshd dc problem
2009/6/23 Corinna Vinschen: On Jun 22 17:48, Reini Urban wrote: Starting the laptop at home, without PDC connection works. I can properly login. But ssh to this box fails with -1 = initgroups (URBANR, 10513) error 1355: DcGetDcName(PDC_REQUIRED) call failed error 2221: UserGetLocalGroups failed I should be able to login with pubkey to my box with sshd when windows lets me in also. That's easier said than done. Apparently your laptop is configured to allow using cached credentials which are used by the machine if it can't connect to a DC. The token information (groups/privileges) is also cached somewhere in a non-documented storage. Whatever Windows is using, it's not accessible for Cygwin. At least I don't know how to do it. Is it possible to detect that one is logged in with a cached credential at least? Then the failing initgroups DcGetDcName(PDC_REQUIRED) can be made non-fatal. Or maybe there's a PDC_OPTIONAL If Cygwin can't connect one of the DCs, then I don't get the group information for the given domain account. If I have no group information, I can only generate a broken user token. The problem here is that initgroups() is called before setuid(). If setuid() would always be called first, we already would have a token and could fetch the groups from there, but that's idle wishing. So, for the time being, the workaround to get a user token is thus: 1. I'll patch Cygwin to ignore the fact that the group information couldn't be fetched from the server. Great! 2. Either you're happy with a restricted token, Restricted token is okay for me. or you use the new logon method 3 as described in http://cygwin.com/1.7/cygwin-ug-net/ntsec.html#ntsec-setuid-overview This results in getting a token right from Windows based on the cached credentials. I'll try password auth then, thanks -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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
xemacs winclient improvements
Several xemacs ideas: * I added -mwindows to the winclient linker step which results in a much improved winclient. I'll take this patch to xemacs-patches by myself. * parseCommandLine() does not work on cygwin this way. It uses the Win32 API to find files, and should be special cased to use the POSIX API. I'll discuss this at xemacs-beta * xemacs-21.5.28-3 uses slow defaults: Compiling in support for extra debugging code. Compiling in support for runtime error checking. WARNING: - WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: - hmm. 21.5.28 is stable for me and upstream. maybe remove this. * build failure on 1.7: In file included from /usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/console-msw.h:41, from /usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/cmdloop.c:43: /usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/syswindows.h:500: error: conflicting types for 'wcstok' /usr/include/wchar.h:92: error: previous declaration of 'wcstok' was here make[1]: *** [cmdloop.o] Error 1 This needs a patch upstream. Maybe I'll take it upstream. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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
Fwd: xemacs winclient improvements
Hi
I'm back in business :)
I switched from native Win32 to cygwin because of the non-matching
Win32 permissions.
Cygwin ACL's are sometimes fucked up by inheritance.
So I have several improvements.
Patches inlined because gmail uploader fails on my proxy
diff -u xemacs-21.5.28/lib-src/winclient.c.orig
xemacs-21.5.28/lib-src/winclient.c
--- xemacs-21.5.28/lib-src/winclient.c.orig 2009-06-24 09:30:22.234375000
+0200
+++ xemacs-21.5.28/lib-src/winclient.c 2009-06-24 10:59:52.43750 +0200
@@ -209,8 +209,8 @@
CloseHandle (pi.hThread);
CloseHandle (pi.hProcess);
- /* Try to connect */
- for (n = 0; n 5; n++)
+ /* Try to connect. Process startup and XEmacs init might be slow */
+ for (n = 0; n 10; n++)
{
Sleep (CONNECT_DELAY);
@@ -408,6 +408,12 @@
/* Retrieve arguments */
while ((arg = getNextArg ((const char**)lpszCommandLine, len)) != NULL)
{
+#ifdef __CYGWIN__
+ /* On cygwin args are already space delimited so pass these args
+ verbatim to XEmacs */
+ fullpath = (char *) xmalloc (len);
+ ret = doFile (hConv, fullpath, arg);
+#else
/* First find the canonical path name */
fullpath = filepart = NULL;
pathlen = GetFullPathName (arg, 0, fullpath, filepart);
@@ -451,7 +457,7 @@
FindClose (hFindFile);
}
-
+#endif
/* Release the path name buffers */
free (fullpath);
free (arg);
diff -u xemacs-21.5.28/lib-src/Makefile.in.in.orig
xemacs-21.5.28/lib-src/Makefile.in.in
--- xemacs-21.5.28/lib-src/Makefile.in.in.orig 2007-05-21
05:50:19.0 +0200
+++ xemacs-21.5.28/lib-src/Makefile.in.in 2009-06-24 09:40:30.25000
+0200
@@ -375,7 +375,7 @@
$(CC) $(cflags) ${srcdir}/../nt/minitar.c $(ldflags) -lz -o $@
winclient: ${srcdir}/winclient.c
- $(CC) $(cflags) ${srcdir}/winclient.c $(ldflags) -o $@
+ $(CC) $(cflags) -mwindows ${srcdir}/winclient.c $(ldflags) -o $@
hexl: ${srcdir}/hexl.c
$(CC) $(cflags) ${srcdir}/hexl.c $(ldflags) -o $@
-- Forwarded message --
From: Reini Urban rur...@x-ray.at
Date: 2009/6/24
Subject: xemacs winclient improvements
To: The Cygwin Mailing List cygwin@cygwin.com
Several xemacs ideas:
* I added -mwindows to the winclient linker step which results in a
much improved winclient.
I'll take this patch to xemacs-patches by myself.
* parseCommandLine() does not work on cygwin this way.
It uses the Win32 API to find files, and should be special cased to
use the POSIX API.
I'll discuss this at xemacs-beta
* xemacs-21.5.28-3 uses slow defaults:
Compiling in support for extra debugging code.
Compiling in support for runtime error checking.
WARNING: -
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: -
hmm. 21.5.28 is stable for me and upstream. maybe remove this.
* build failure on 1.7:
In file included from
/usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/console-msw.h:41,
from
/usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/cmdloop.c:43:
/usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/syswindows.h:500:
error: conflicting types for 'wcstok'
/usr/include/wchar.h:92: error: previous declaration of 'wcstok' was here
make[1]: *** [cmdloop.o] Error 1
This needs a patch upstream. Maybe I'll take it upstream.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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] sshd dc problem
On Jun 24 10:45, Reini Urban wrote: 2009/6/23 Corinna Vinschen: On Jun 22 17:48, Reini Urban wrote: I should be able to login with pubkey to my box with sshd when windows lets me in also. That's easier said than done. Apparently your laptop is configured to allow using cached credentials which are used by the machine if it can't connect to a DC. The token information (groups/privileges) is also cached somewhere in a non-documented storage. Whatever Windows is using, it's not accessible for Cygwin. At least I don't know how to do it. Is it possible to detect that one is logged in with a cached credential at least? I don't know. I don't think so. And even then there's the problem that more than one user session can be active, so you would have to find the right one first. Hmm. Come to think of it, what Cygwin could try starting with Windows XP is to use Terminal Service functions to see if the user is already logged in, and if so, use that user's token for the setuid call. I never tried that before, so I don't know if that works as desired. Anyway, that's something to try for a later version of Cygwin. Then the failing initgroups DcGetDcName(PDC_REQUIRED) can be made non-fatal. Or maybe there's a PDC_OPTIONAL I'm not requiring the PDC, at least post-NT4. The function calls DsGetDcNameW asking for any DC. If that fails, it just tries it again with the DS_FORCE_REDISCOVERY flag. So, for the time being, the workaround to get a user token is thus: 1. I'll patch Cygwin to ignore the fact that the group information couldn't be fetched from the server. Great! 2. Either you're happy with a restricted token, Restricted token is okay for me. It's *very* restricted. It only contains the barest groups, plus Users and your primary domain group as set in /etc/passwd. If you need more supplementary groups, you have to add yourself to the respective /etc/group entries. or you use the new logon method 3 as described in http://cygwin.com/1.7/cygwin-ug-net/ntsec.html#ntsec-setuid-overview This results in getting a token right from Windows based on the cached credentials. I'll try password auth then, thanks Using password auth doesn't solve the initgroups problem, unfortunately. You'll still need the aforementioned patch to Cygwin. 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
Cygwin-1.7 support
Cygwin 1.7 comes with wchar.h (finally) so we need this patch. (inlined) Tested okay. diff -u xemacs-21.5.28/src/syswindows.h.orig xemacs-21.5.28/src/syswindows.h --- xemacs-21.5.28/src/syswindows.h.orig2006-12-08 03:22:02.0 +0100 +++ xemacs-21.5.28/src/syswindows.h 2009-06-24 12:01:06.546875000 +0200 @@ -481,7 +481,10 @@ #ifdef CYGWIN -/* All but wcscmp and wcslen left out of Cygwin headers -- but present +#if (CYGWIN_VERSION_API_MINOR = 181) +# include wchar.h +#else +/* All but wcscmp and wcslen left out of Cygwin 1.5 headers -- but present in /usr/include/mingw/string.h! */ wchar_t* wcscat (wchar_t*, const wchar_t*); wchar_t* wcschr (const wchar_t*, wchar_t); @@ -499,6 +502,7 @@ wchar_t* wcsstr (const wchar_t*, const wchar_t*); wchar_t* wcstok (wchar_t*, const wchar_t*); size_t wcsxfrm (wchar_t*, const wchar_t*, size_t); +#endif /* CYGWIN 1.5 */ #endif /* CYGWIN */ -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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
undef WIN32_FILENAMES with cygwin-1.7
cygwin-1.7 removed support for accepting win32 style pathnames. xemacs should follow. The particular problem was file-truename returning a fabricated windows path, instead of the POSIX path, which for example failed the mule testsuite for me. diff -u xemacs-21.5.28/src/fileio.c.orig xemacs-21.5.28/src/fileio.c --- xemacs-21.5.28/src/fileio.c.orig2007-02-22 17:19:43.0 +0100 +++ xemacs-21.5.28/src/fileio.c 2009-06-24 12:35:05.703125000 +0200 @@ -59,7 +59,11 @@ #endif /* HPUX */ #ifdef WIN32_ANY +#if (CYGWIN_VERSION_API_MINOR = 181) +#undef WIN32_FILENAMES +#else #define WIN32_FILENAMES +#endif #include syswindows.h #define IS_DRIVE(x) isalpha (x) /* Need to lower-case the drive letter, or else expanded -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: undef WIN32_FILENAMES with cygwin-1.7
On Jun 24 12:43, Reini Urban wrote: cygwin-1.7 removed support for accepting win32 style pathnames. Huh? No, it didn't. Win32 paths are still accepted. What is your exact problem? 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
Numpy error in Python.
Hello All, I have imported the python-numpy package and am trying to import numpy into python on bash.I am getting this error as shown below.Please let me know what to do. $ python Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. import numpy numpy.test() Running unit tests for numpy Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/site-packages/numpy/testing/nosetester.py, line 240, in test self._show_system_info() File /usr/lib/python2.5/site-packages/numpy/testing/nosetester.py, line 151, in _show_system_info nose = import_nose() File /usr/lib/python2.5/site-packages/numpy/testing/nosetester.py, line 51, in import_nose raise ImportError(msg) ImportError: Need nose = 0.10.0 for tests - see http://somethingaboutorange.com/mrl/projects/nose exit() Thanks and Regards, Sandeep. -- 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: Numpy error in Python.
Sandeep, On Wed, Jun 24, 2009 at 05:18:15PM +0530, Sandeep Devadas wrote: I have imported the python-numpy package and am trying to import numpy into python on bash.I am getting this error as shown below.Please let me know what to do. $ python Python 2.5.2 (r252:60911, Dec? 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. import numpy numpy.test() [snip] ??? raise ImportError(msg) ImportError: Need nose = 0.10.0 for tests - see http://somethingaboutorange.com/mrl/projects/nose exit() Seems like you need to (build and) install nose. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: Numpy error in Python.
Hi There, I installed nose as per your instructions and now im getting this error.Please let me know what to do. $ python Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. import numpy numpy.test() Running unit tests for numpy NumPy version 1.2.1 NumPy is installed in /usr/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Dec 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] nose version 0.11.1 Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/site-packages/numpy/testing/nosetester.py, line 278, in test t = NumpyTestProgram(argv=argv, exit=False, plugins=plugins) File /bin/nose-0.11.1/nose-0.11.1/nose/core.py, line 113, in __init__ argv=argv, testRunner=testRunner, testLoader=testLoader) File /usr/lib/python2.5/unittest.py, line 767, in __init__ self.parseArgs(argv) File /bin/nose-0.11.1/nose-0.11.1/nose/core.py, line 130, in parseArgs self.config.configure(argv, doc=self.usage()) File /bin/nose-0.11.1/nose-0.11.1/nose/config.py, line 249, in configure options, args = self._parseArgs(argv, cfg_files) File /bin/nose-0.11.1/nose-0.11.1/nose/config.py, line 237, in _parseArgs return parser.parseArgsAndConfigFiles(argv[1:], cfg_files) File /bin/nose-0.11.1/nose-0.11.1/nose/config.py, line 132, in parseArgsAndConfigFiles self._applyConfigurationToValues(self._parser, config, values) File /bin/nose-0.11.1/nose-0.11.1/nose/config.py, line 118, in _applyConfigurationToValues name=name, filename=filename) File /bin/nose-0.11.1/nose-0.11.1/nose/config.py, line 234, in warn_sometimes raise ConfigError(msg) nose.config.ConfigError: Error reading config file 'setup.cfg': no such option 'doctest-extension' On Wed, Jun 24, 2009 at 5:32 PM, Jason Tishlerja...@tishler.net wrote: Sandeep, On Wed, Jun 24, 2009 at 05:18:15PM +0530, Sandeep Devadas wrote: I have imported the python-numpy package and am trying to import numpy into python on bash.I am getting this error as shown below.Please let me know what to do. $ python Python 2.5.2 (r252:60911, Dec? 2 2008, 09:26:14) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. import numpy numpy.test() [snip] ??? raise ImportError(msg) ImportError: Need nose = 0.10.0 for tests - see http://somethingaboutorange.com/mrl/projects/nose exit() Seems like you need to (build and) install nose. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xemacs winclient improvements
2009/6/24 Reini Urban: * xemacs-21.5.28-3 uses slow defaults: I'm using now: --with-optimization \ --with-modules=yes \ with-optimization is fast enough now for me. with-modules to enable integration of various old modules of mine: w32reg, w32ole and w32hhelp from http://autocad.xarch.at/lsp_tools/ntemacs/emodules/ hmm. 21.5.28 is stable for me and upstream. maybe remove this. All tests pass except mule, which accesses /tmp/USERNAME/??? base64-tests.el: 1234 of 1234 tests successful (100%). byte-compiler-tests.el: 104 of 104 tests successful (100%). c-tests.el: 4 of 4 tests successful (100%). case-tests.el: 1148 of 1148 tests successful (100%). ccl-tests.el:4570 of 4570 tests successful (100%). database-tests.el: 10 of10 tests successful (100%). extent-tests.el: 194 of 194 tests successful (100%). hash-table-tests.el: 9866 of 9866 tests successful (100%). iso-ir-196-test.el: 2 of 2 tests successful (100%). lisp-reader-tests.el: 52 of52 tests successful (100%). lisp-tests.el: 3766 of 3766 tests successful (100%). md5-tests.el: 56 of56 tests successful (100%). os-tests.el: 20 of20 tests successful (100%). regexp-tests.el: 350 of 350 tests successful (100%). region-tests.el: 28 of28 tests successful (100%). symbol-tests.el: 246 of 246 tests successful (100%). syntax-tests.el: 72 of78 tests successful ( 92%). (known bugs) tag-tests.el: 6 of 6 tests successful (100%). weak-tests.el:140 of 140 tests successful (100%). -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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/sluggish response (system task at 50%)
Dave Korn wrote: Gene Smith wrote: Larry Hall (Cygwin) wrote: Gene Smith wrote: snip Since I don't have a HOME env var in windows, cygwin is getting the cygwin HOME from /etc/passwd. So I tried it both ways. With 1.5 I set home to be the empty directory /home/smited (under c:/cygwin). It didn't make it any faster. With beta-1.7 I set home to /cygdrive/c/Documents and Settings/smited (where all the cruft is) and it didn't make it any slower. So where cygwin points $HOME at terminal startup does not seem to have an effect for me. Current version 1.5 is slow while beta-1.7 is fast, for still unknown reasons. I guess you're stuck looking at strace output to see if that helps pinpoint the problem... I ran the make under strace -o outfile make but I couldn't really tell what I was looking at in the outfile. The main thing to look at is the absolute and relative timestamps in the first two columns, and see if any of the delays look inordinately long, that would indicate a specific syscall ran into a big delay. cheers, DaveK Well, it was OK at first after a reinstall with the default setup, enough to run and build a project with an cross compiled embedded toolchain. But when I install gcc, make, svn etc (enough to compile the openocd project) then it is slow again. I ran strace on the make process again and see lines like this that look bad: 3688545 13178956 [proc_waiter] make 868 pinfo::maybe_set_exit_code_from_windows: pid 9176, exit value - old 0x800, windows 0xDEADBEEF, cygwin 0x800n/ The deadbeef sounds like a marker of some sort? This delay occur repetitively and many times during the build. I think the *exact* same problem is pointed to by this thread: http://sources.redhat.com/ml/cygwin/2007-02/msg00571.html Unfortunately, no solution is described. :( If I set my windows path into /usr/bin of cygwin, I can run the same build in a dos cmd window and it runs fast. For me, it is only slow in the cygwin terminal. However, for my co-worker, it seems to be slow for him too in the dos box (I have no idea why). -- 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
/dev/ttyUSB0: No such file or directory
Hello. I am new to the Cygwin and have a problem connecting a device with serial output to the computer throw USB adapter. In Linux it's name is /dev/ttyUSB0. I have no /dev/ttyUSB0 device in /dev (but ttyS0 works). So I plug the USB cable in, then trying to: $ cat /dev/ttyUSB0 cat: /dev/ttyUSB0: No such file or directory ? -- 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/sluggish response (system task at 50%)
On Wed, Jun 24, 2009 at 10:21:39AM -0400, Gene Smith wrote: Dave Korn wrote: Gene Smith wrote: Larry Hall (Cygwin) wrote: Gene Smith wrote: snip Since I don't have a HOME env var in windows, cygwin is getting the cygwin HOME from /etc/passwd. So I tried it both ways. With 1.5 I set home to be the empty directory /home/smited (under c:/cygwin). It didn't make it any faster. With beta-1.7 I set home to /cygdrive/c/Documents and Settings/smited (where all the cruft is) and it didn't make it any slower. So where cygwin points $HOME at terminal startup does not seem to have an effect for me. Current version 1.5 is slow while beta-1.7 is fast, for still unknown reasons. I guess you're stuck looking at strace output to see if that helps pinpoint the problem... I ran the make under strace -o outfile make but I couldn't really tell what I was looking at in the outfile. The main thing to look at is the absolute and relative timestamps in the first two columns, and see if any of the delays look inordinately long, that would indicate a specific syscall ran into a big delay. Well, it was OK at first after a reinstall with the default setup, enough to run and build a project with an cross compiled embedded toolchain. But when I install gcc, make, svn etc (enough to compile the openocd project) then it is slow again. I ran strace on the make process again and see lines like this that look bad: 3688545 13178956 [proc_waiter] make 868 pinfo::maybe_set_exit_code_from_windows: pid 9176, exit value - old 0x800, windows 0xDEADBEEF, cygwin 0x800n/ Some observations but no explanations: 1) Large delta times do not mean that there is automatically something wrong with Cygwin. If you straced sleep 3600 you'd see at least one large delta time. 2) The DEADBEEF is expected. 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
--prefix tag is ignored when installing a rpm
Hello, I'm trying to use the --prefix command to relocate an RPM on install. When building the spec file then running the command: rpm -Uvh --prefix /opt/drew rpm-name.rpm In a Unix environment it works fine and installs to /opt/drew. However when running the same command in Cygwin it ignores --prefix entirely and just installs to the default directory. I do have to include the --nodeps tag in Cygwin because without it I run into the error Failed Dependencies: /bin/sh is needed by rpm-name I'm pretty sure I installed all the RPM packages when I installed Cygwin, but I don't know how to check if that is so. I've also tried the --relocate tag but that is also ignored. If anyone has any ideas I'd greatly appreciate it. Thank you, Drew -- View this message in context: http://www.nabble.com/--prefix-tag-is-ignored-when-installing-a-rpm-tp24187945p24187945.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: How to avoid having shell scripts which fail from killing Emacs shell?
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Eric Blake Sent: Tuesday, June 23, 2009 9:04 AM To: cygwin@cygwin.com Subject: Re: How to avoid having shell scripts which fail from killing Emacs shell? David Karr dkarr at real.com writes: I'm not sure how complicated it needs to be. My test case gathers a couple of parameters and then calls a Java (JDK 1.6.0_14) class. I found that the key is whether the Java class reads from stdin or not. I just tried changing my script to instead just do a read with a prompt. This does not kill the shell at the end of the script. When I do it in Java, it kills the shell at the end of the script. Weird. Hmm. JDK is a native windows app, not a cygwin app. So maybe the key here is not just reading stdin, but passing stdin to a non-cygwin app. That seems reasonable. In the past, I believe I've seen references to issues related to I/O interactions with non-cygwin apps. Does that notion give any one else a clue to why this might be happening, or how to mitigate it? -- 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 winbase.h (ilockcmpexch) compile error
I'm trying to build Cygwin 1.7 from CVS to debug an ImageMagick problem on server 2008 that causes an access violation in cygwin1.dll. Doe anyone know the work around for this issue? g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) winsup/cygwin/winbase.h: In member function `int pthread_mutex::_trylock(pthread*)': winsup/cygwin/winbase.h:59: warning: volatile register variables don't work as you might wish winsup/cygwin/winbase.h:63: error: can't find a register in class `AREG' while reloading `asm' I presume it is related to this change: http://cygwin.com/ml/cygwin-patches/2009-q2/msg00072.html but I haven't had time to dig into the full problem. Thanks for any help available. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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
cygcheck triggers Wow6432Node infinite loop on Windows Server 2008
Hi there, On a Windows Server 2008, running cronbug from the (bash) command line results in an ever increasing cronbug.txt file because cygcheck walks the registry and gets into an infinite loop. It will repeatedly find these entries, deeper and deeper in the registry: Cygnus Solutions Cygnus Solutions\Cygwin Cygnus Solutions\Cygwin\mounts v2 Cygnus Solutions\Cygwin\mounts v2\/ Cygnus Solutions\Cygwin\mounts v2\/usr/bin Cygnus Solutions\Cygwin\mounts v2\/usr/lib Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Wow6432Node\Wow6432Node\Cygnus Solutions Wow6432Node is Windows-on-windows, and allows registry entries for 32 bit applications to be stored along side registry entries for 64 bit applications of the same name (allowing for different entries for 64 bit and 32 bit apps). The infinite loop behaviour is known and fixed by Microsoft by making the registry key HKLM\Software\Wow6432Node hidden from RegEnumKeyEx in the 32 bit hive. http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms724072%28VS.85%29.aspx Many registry cleaners are (still) struggling with this, as are registry backup utilities, and also, it appears, cygcheck. --GJ-- -- 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
gcc-4 is broken on both cygwin-1.5 and cygwin-1.7
It cost me a lot of time but I verified that gcc-4 is malfunctioning on both versions. It's impossible to build boost-1.38 or build-1.39, even if you build only static libs. I had to use the gcc 4 that I had built myself previously on cygwin-1.5 And I think boost is pretty essential. Did you patch gcc-4 or something? Whatever it is, I would like an unpatched version if possible, as a C++ user. Could you make an alternative package please? It must be that auto-import thingie that's FUBAR'd. At any rate, C++/boost users attention: don't use cygwin's own gcc-4 package, it's badly broken. Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara Researcher, Erendiz Superbilgisayar Ltd. http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct -- 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] mount -c is lost after reboot
Hi, Whenever I do a mount -c / in cygwin 1.7, it seems to revert back to /cygdrive after rebooting on Windows XP x64. Any ideas on how to have the mount point change persist through reboots? Thanks, -Edward -- 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 winbase.h (ilockcmpexch) compile error
Brian Ford wrote: I'm trying to build Cygwin 1.7 from CVS to debug an ImageMagick problem on server 2008 that causes an access violation in cygwin1.dll. Doe anyone know the work around for this issue? g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) winsup/cygwin/winbase.h: In member function `int pthread_mutex::_trylock(pthread*)': winsup/cygwin/winbase.h:59: warning: volatile register variables don't work as you might wish winsup/cygwin/winbase.h:63: error: can't find a register in class `AREG' while reloading `asm' I presume it is related to this change: http://cygwin.com/ml/cygwin-patches/2009-q2/msg00072.html but I haven't had time to dig into the full problem. Thanks for any help available. Argh. Try hacking out the 'register' and '__asm (%eax)' from the declaration of the 'ret' variable on line 59. Send me the generated thread.s file offlist after finishing the build with --save-temps in the CFLAGS and I'll check that the codegen is correct. (Haven't used 3.x to build the DLL in ages myself.) 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: /dev/ttyUSB0: No such file or directory
Leonid Krashenko schrieb: Hello. I am new to the Cygwin and have a problem connecting a device with serial output to the computer throw USB adapter. In Linux it's name is /dev/ttyUSB0. I have no /dev/ttyUSB0 device in /dev (but ttyS0 works). So I plug the USB cable in, then trying to: $ cat /dev/ttyUSB0 cat: /dev/ttyUSB0: No such file or directory Nevermind the name difference. Look up the proper COM name in device manager, and use /dev/com7 (adjust the number as needed). Note that Cygwin 1.5 only maps 16 serial devices (this is a problem for me as the crappy Toshiba Bluetooth software assigns a gazillion of Bluetooth COM ports it never needs and I never configured...), in doubt just remove an unused one (preferably one with a low number) in device manager and unplug and re-plug your USB to serial converter, Windows should then assign the lowest untaken number automatically. -- 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: gcc-4 is broken on both cygwin-1.5 and cygwin-1.7
Eray Ozkural wrote: It cost me a lot of time but I verified that gcc-4 is malfunctioning on both versions. It is possible you have actually verified what you think you have verified, but you give no details so it's impossible to evaluate your methodology. It's impossible to build boost-1.38 or build-1.39, even if you build only static libs. So.. what? Error message? Computer blows up? Hippos attack? What *happens*? I had to use the gcc 4 that I had built myself previously on cygwin-1.5 And I think boost is pretty essential. Did you patch gcc-4 or something? There are numerous patches to GCC-4. They all fixed bugs or added required enhancements, and I spent a great deal of time running regression tests before and after applying each patch and didn't observe any testsuite failures. There is a known non-conformance problem with the shared libstdc++ DLL (can't interpose replaced operator new/delete) which I'm currently working to fix. Static linking should be fully functional though. Whatever it is, I would like an unpatched version if possible, as a C++ user. Could you make an alternative package please? Anyone is free to compile anything they like, but I'm certainly not going to go to that much trouble on the basis of an angry rant with zero information in it. It must be that auto-import thingie that's FUBAR'd. Your diagnosis appears to be evidence-free guesswork. At any rate, C++/boost users attention: don't use cygwin's own gcc-4 package, it's badly broken. You really haven't explained or analysed the problem in any detail. The most likely explanation is that GCC is fine and you've run into a binutils problem, but without any details from you of what exactly you think is broken it's not exactly easy to proceed. Come on. If you want assistance, please write a proper bug report. With information, and details, and all that useful stuff. Then we can make it *work*. 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: cygcheck triggers Wow6432Node infinite loop on Windows Server 2008
On Wed, Jun 24, 2009 at 02:00:52PM -0400, GJ Hagenaars wrote: Hi there, On a Windows Server 2008, running cronbug from the (bash) command line results in an ever increasing cronbug.txt file because cygcheck walks the registry and gets into an infinite loop. It will repeatedly find these entries, deeper and deeper in the registry: Cygnus Solutions Cygnus Solutions\Cygwin Cygnus Solutions\Cygwin\mounts v2 Cygnus Solutions\Cygwin\mounts v2\/ Cygnus Solutions\Cygwin\mounts v2\/usr/bin Cygnus Solutions\Cygwin\mounts v2\/usr/lib Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Wow6432Node\Wow6432Node\Cygnus Solutions Wow6432Node is Windows-on-windows, and allows registry entries for 32 bit applications to be stored along side registry entries for 64 bit applications of the same name (allowing for different entries for 64 bit and 32 bit apps). The infinite loop behaviour is known and fixed by Microsoft by making the registry key HKLM\Software\Wow6432Node hidden from RegEnumKeyEx in the 32 bit hive. http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms724072%28VS.85%29.aspx Many registry cleaners are (still) struggling with this, as are registry backup utilities, and also, it appears, cygcheck. Which version of cygcheck is this? Does it come from 1.7 or 1.5? 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: gcc-4 is broken on both cygwin-1.5 and cygwin-1.7
On Wed, Jun 24, 2009 at 09:09:52PM +0300, Eray Ozkural wrote: It cost me a lot of time but I verified that gcc-4 is malfunctioning on both versions. It's impossible to build boost-1.38 or build-1.39, even if you build only static libs. I had to use the gcc 4 that I had built myself previously on cygwin-1.5 And I think boost is pretty essential. Did you patch gcc-4 or something? Whatever it is, I would like an unpatched version if possible, as a C++ user. Could you make an alternative package please? It must be that auto-import thingie that's FUBAR'd. At any rate, C++/boost users attention: don't use cygwin's own gcc-4 package, it's badly broken. The person who maintains gcc/g++ is ready, willing, and able to fix problems. This content free report does not give him anything to work with, however. You have to do a much better job of reporting the problem if you truly want a solution and don't just want to complain. -- Christopher Faylor Cygwin Co-Project Leader -- 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/sluggish response (system task at 50%)
Gene Smith wrote: Well, it was OK at first after a reinstall with the default setup, enough to run and build a project with an cross compiled embedded toolchain. But when I install gcc, make, svn etc (enough to compile the openocd project) then it is slow again. I ran strace on the make process again and see lines like this that look bad: 3688545 13178956 [proc_waiter] make 868 pinfo::maybe_set_exit_code_from_windows: pid 9176, exit value - old 0x800, windows 0xDEADBEEF, cygwin 0x800n/ The deadbeef sounds like a marker of some sort? This delay occur repetitively and many times during the build. I think the *exact* same problem is pointed to by this thread: http://sources.redhat.com/ml/cygwin/2007-02/msg00571.html Unfortunately, no solution is described. :( If I set my windows path into /usr/bin of cygwin, I can run the same build in a dos cmd window and it runs fast. For me, it is only slow in the cygwin terminal. However, for my co-worker, it seems to be slow for him too in the dos box (I have no idea why). Going back to beta-1.7 default install that ran fast I noticed that it was actually using a mingw32 version of make from winavr project and not the cygwin make. The default cygwin install does not include make. When I load the cygwin make package and the build uses it (since cygwin puts its paths ahead of windows path) the build slows way down. If I remove make from cygwin's /bin it speeds back up (since using the mingw32 make). The build referred to above uses a toolchain built for mingw32, not cygwin's gcc. So as long as make is also built for mingw32 the build is fast when run from cygwin terminal or dos window. With make being the cygwin version, the build is slow in all cases. What does this mean? Am I doing something illegal mixing cygwin and mingw programs? -- 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] mount -c is lost after reboot
On Wed, Jun 24, 2009 at 02:11:32PM -0400, Edward Lam wrote: Whenever I do a mount -c / in cygwin 1.7, it seems to revert back to /cygdrive after rebooting on Windows XP x64. Any ideas on how to have the mount point change persist through reboots? You need to modify /etc/fstab. That's a fundamental difference in Cygwin 1.5. Mount points are no longer persistent unless you go out of your way to make them so. 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: 1.7 winbase.h (ilockcmpexch) compile error
On Wed, Jun 24, 2009 at 07:40:39PM +0100, Dave Korn wrote: Brian Ford wrote: I'm trying to build Cygwin 1.7 from CVS to debug an ImageMagick problem on server 2008 that causes an access violation in cygwin1.dll. Doe anyone know the work around for this issue? g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) winsup/cygwin/winbase.h: In member function `int pthread_mutex::_trylock(pthread*)': winsup/cygwin/winbase.h:59: warning: volatile register variables don't work as you might wish winsup/cygwin/winbase.h:63: error: can't find a register in class `AREG' while reloading `asm' I presume it is related to this change: http://cygwin.com/ml/cygwin-patches/2009-q2/msg00072.html but I haven't had time to dig into the full problem. Thanks for any help available. Argh. Try hacking out the 'register' and '__asm (%eax)' from the declaration of the 'ret' variable on line 59. Send me the generated thread.s file offlist after finishing the build with --save-temps in the CFLAGS and I'll check that the codegen is correct. (Haven't used 3.x to build the DLL in ages myself.) Me neither. I'm comfortable making gcc 4.x a requirement for building Cygwin and its utilities. Apparently Corinna is using 4.x since this change predates at least two previous 1.7.0 releases. 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: [1.7] mount -c is lost after reboot
On Wed, Jun 24, 2009 at 03:35:35PM -0400, Christopher Faylor wrote: On Wed, Jun 24, 2009 at 02:11:32PM -0400, Edward Lam wrote: Whenever I do a mount -c / in cygwin 1.7, it seems to revert back to /cygdrive after rebooting on Windows XP x64. Any ideas on how to have the mount point change persist through reboots? You need to modify /etc/fstab. That's a fundamental difference in Cygwin 1.5. 1.7. 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: Slow/sluggish response (system task at 50%)
Gene Smith wrote: snip Going back to beta-1.7 default install that ran fast I noticed that it was actually using a mingw32 version of make from winavr project and not the cygwin make. The default cygwin install does not include make. When I load the cygwin make package and the build uses it (since cygwin puts its paths ahead of windows path) the build slows way down. If I remove make from cygwin's /bin it speeds back up (since using the mingw32 make). The build referred to above uses a toolchain built for mingw32, not cygwin's gcc. So as long as make is also built for mingw32 the build is fast when run from cygwin terminal or dos window. With make being the cygwin version, the build is slow in all cases. What does this mean? Am I doing something illegal mixing cygwin and mingw programs? Interesting. I'm not sure why using Cygwin's 'make' would slow things down dramatically when running from a Cygwin terminal or shell. I can see there being some overhead if that's the only Cygwin process you're running, since there would be a Cygwin initialization cost to start 'make' if there were no other Cygwin processes running at the time. I very much doubt that this would account for the dramatic slow-down you've reported. So while certainly there's an issue here, it seems like the work-around you've found is viable. And it does make more sense than mixing and matching Cygwin and Mingw. Are you able to reproduce this problem for any kind of package? It might be helpful to know that building package or tarball 'foo' demonstrates the problem. -- 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? -- 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: gcc-4 is broken on both cygwin-1.5 and cygwin-1.7
On 24/06/2009 13:09, Eray Ozkural wrote: It cost me a lot of time but I verified that gcc-4 is malfunctioning on both versions. I think I can safely say that gcc-4.3 is working just fine, having used it to build hundreds of packages, both C and C++. It's impossible to build boost-1.38 or build-1.39, even if you build only static libs. Actually, I think it is boost's fault. They changed something in boost-jam's implib generation that broke the build, but I haven't had a chance to track it down yet. 1.37 builds and AFAICS works fine. I had to use the gcc 4 that I had built myself previously on cygwin-1.5 And I think boost is pretty essential. Your opinion, I suppose. Did you patch gcc-4 or something? Whatever it is, I would like an unpatched version if possible, as a C++ user. Could you make an alternative package please? It must be that auto-import thingie that's FUBAR'd. Of course it is patched; it wouldn't work right on Cygwin if it wasn't (not that Dave isn't trying to push patches upstream as best possible). At any rate, C++/boost users attention: don't use cygwin's own gcc-4 package, it's badly broken. Sigh, maybe I should just ITA 1.37 from Ports so people stop complaining so much about boost. Yaakov -- 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: cygcheck triggers Wow6432Node infinite loop on Windows Server 2008
2009/6/24 GJ Hagenaars: Hi there, On a Windows Server 2008, running cronbug from the (bash) command line results in an ever increasing cronbug.txt file because cygcheck walks the registry and gets into an infinite loop. It will repeatedly find these entries, deeper and deeper in the registry: Cygnus Solutions Cygnus Solutions\Cygwin Cygnus Solutions\Cygwin\mounts v2 Cygnus Solutions\Cygwin\mounts v2\/ Cygnus Solutions\Cygwin\mounts v2\/usr/bin Cygnus Solutions\Cygwin\mounts v2\/usr/lib Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Wow6432Node\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node\Wow6432Node\Wow6432Node\Cygnus Solutions Wow6432Node is Windows-on-windows, and allows registry entries for 32 bit applications to be stored along side registry entries for 64 bit applications of the same name (allowing for different entries for 64 bit and 32 bit apps). The infinite loop behaviour is known and fixed by Microsoft by making the registry key HKLM\Software\Wow6432Node hidden from RegEnumKeyEx in the 32 bit hive. Gah. Why oh why can't Microsoft ever create an elegant and straightforward solution to anything? Program Files (x86), Windows on Windows 64, Wow6432Node, 64-bit DLLs in System32, and 32-bit DLLs in SysWOW64. This is all so ugly and confusing that you have to wonder whether they're not deliberately trying to obfuscate stuff. 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
Re: Slow/sluggish response (system task at 50%)
Larry Hall (Cygwin) wrote: Interesting. I'm not sure why using Cygwin's 'make' would slow things down dramatically when running from a Cygwin terminal or shell. I can Note that cygwin's make is just plain slower that mingw's make to begin with. I'm not quite sure I can explain the ~25 times speed difference that Gene experiences but I can definitely vouch for at least a ~7 times speed difference (which I think it primarily due to forking). Here's a speed test taken from an old thread on the cygwin mailing list. I did this test just right now with virtually no CPU usage on the same machine (WinXP SP2 x64, Intel Core i7 2.66 GHz): (MINGW) $ uname -a MINGW32_NT-5.2 SEOUL 1.0.11(0.46/3/2) 2009-05-23 19:33 i686 Msys $ time -p for ((i=1; i100; i++)); do var=$(echo $i | tr [a-z] [A-Z]); done real 1.51 user 0.58 sys 0.82 (CYGWIN 1.7) $ uname -a CYGWIN_NT-5.2-WOW64 seoul 1.7.0(0.210/5/3) 2009-06-18 12:51 i686 Cygwin $ time -p for ((i=1; i100; i++)); do var=$(echo $i | tr [a-z] [A-Z]); done real 10.45 user 0.76 sys 1.53 Regards, -Edward Larry Hall (Cygwin) wrote: Gene Smith wrote: snip Going back to beta-1.7 default install that ran fast I noticed that it was actually using a mingw32 version of make from winavr project and not the cygwin make. The default cygwin install does not include make. When I load the cygwin make package and the build uses it (since cygwin puts its paths ahead of windows path) the build slows way down. If I remove make from cygwin's /bin it speeds back up (since using the mingw32 make). The build referred to above uses a toolchain built for mingw32, not cygwin's gcc. So as long as make is also built for mingw32 the build is fast when run from cygwin terminal or dos window. With make being the cygwin version, the build is slow in all cases. What does this mean? Am I doing something illegal mixing cygwin and mingw programs? Interesting. I'm not sure why using Cygwin's 'make' would slow things down dramatically when running from a Cygwin terminal or shell. I can see there being some overhead if that's the only Cygwin process you're running, since there would be a Cygwin initialization cost to start 'make' if there were no other Cygwin processes running at the time. I very much doubt that this would account for the dramatic slow-down you've reported. So while certainly there's an issue here, it seems like the work-around you've found is viable. And it does make more sense than mixing and matching Cygwin and Mingw. Are you able to reproduce this problem for any kind of package? It might be helpful to know that building package or tarball 'foo' demonstrates the problem. -- 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/sluggish response (system task at 50%)
Edward Lam wrote: Larry Hall (Cygwin) wrote: Interesting. I'm not sure why using Cygwin's 'make' would slow things down dramatically when running from a Cygwin terminal or shell. I can Note that cygwin's make is just plain slower that mingw's make to begin with. I'm not quite sure I can explain the ~25 times speed difference that Gene experiences but I can definitely vouch for at least a ~7 times speed difference (which I think it primarily due to forking). Here's a speed test taken from an old thread on the cygwin mailing list. I did this test just right now with virtually no CPU usage on the same machine (WinXP SP2 x64, Intel Core i7 2.66 GHz): (MINGW) $ uname -a MINGW32_NT-5.2 SEOUL 1.0.11(0.46/3/2) 2009-05-23 19:33 i686 Msys $ time -p for ((i=1; i100; i++)); do var=$(echo $i | tr [a-z] [A-Z]); done Sure, we all know that Cygwin provides Linux emulation and suffers some overhead for it. But timings from an individual machine can be misleading. Running this through multiple times for both Mingw and Cygwin 1.7 on my similarly equipped machine, I see Cygwin is somewhere between 1.7 and 2.25 times slower. Whether yours or my result is more typical, I can't say. But as you noted, neither data set provides much justification for the results reported. -- 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? -- 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 winbase.h (ilockcmpexch) compile error
On Wed, 24 Jun 2009, Christopher Faylor wrote: On Wed, Jun 24, 2009 at 07:40:39PM +0100, Dave Korn wrote: Brian Ford wrote: g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) winsup/cygwin/winbase.h: In member function `int pthread_mutex::_trylock(pthread*)': winsup/cygwin/winbase.h:59: warning: volatile register variables don't work as you might wish winsup/cygwin/winbase.h:63: error: can't find a register in class `AREG' while reloading `asm' http://cygwin.com/ml/cygwin-patches/2009-q2/msg00072.html (Haven't used 3.x to build the DLL in ages myself.) I'm comfortable making gcc 4.x a requirement for building Cygwin and its utilities. I'm prepared to work the problem as my time permits, but I assume you are going to get far less help with Cygwin debugging/development if you require a compiler that is not yet in the distribution. (I know you think you get next to no help now, and that this isn't a big issue for those that do contribute, but it still doesn't seem like a very good idea.) -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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
More info on boost and gcc-4
Hi there, Thanks for all the replies. I'm not subscribed to the list (not yet) so please CC your replies to me. I am going to try to give as much information as I can. Here is what's happening. If I use a *vanilla* gcc 4.x that I compiled, everything just works fine with boost. Here is the version that I'm using successfully at the present. It's been some time since I compiled this one: $ g++ --version g++ (GCC) 4.3.1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Otherwise, unfortunately, everything collapses, and it is highly unlikely that the fault lies with the boost library as the package maintainer suggested. Boost is a portable library that's being tested on many platforms regularly and I have never seen a major crash like this on any other system (linux and mac tested myself). It is not just my idea that boost is essential. What do you believe the next C++ standard library be? How did I build boost? Well, I followed the standard build procedure of course. In my first attempts, having been frustrated by my apparent inability to make a shared library, I had built a static library. I used the following procedure for boost-1.38: Uninstall all boost include files /usr/include/boost* and libraries /usr/local/l ib/*boost* as well. tar -xzf boost-1_38.tar.gz cd boost-1_38_0 ./configure --with-libraries=filesystem,graph,program_options,regex,system In the file Makefile, change the line #BJAM_CONFIG= -sICU_PATH=/usr to #BJAM_CONFIG=-d2 release link=static runtime-link=static cxxflags=-DBOOST_POSIX_ API=1 optimization=speed (Boost apparently does not work with vanilla autotools on cygwin except when libraries are static). make make install cd /usr/local/include ln -s boost-1_38/boost boost Just to make sure we're on the same page, and I'm doing nothing funny. The boost-1.39 build proceeds similarly. However, as the package maintainer might have noticed, the build procedure changed considerably so there is no more a configure or Makefile. You give the --with-libraries option to bootstrap.sh and you can also give a --disable-icu IIRC. (You can't use ICU with static linking so it must be disabled) Then, you must change the gcc configuration so that the cygwin gcc-4 is used instead of gcc. (user-config.jam). Jam is a terrible tool but unfortunately with the current boost we have to stick to it. I don't think it honors environment variables like CXX and has some of the worst documentation (and design) I ever saw in a system tool :( I made the following change in ./tools/build/v2/user-config.jam # Configure specific gcc version, giving alternative name to use. using gcc : 4.3 : g++-4 ; Afterwards you give the bjam options directly like this: $ bjam -d2 release link=static runtime-link=static cxxflags=-DBOOST_POSIX_API=1 optimization=speed install And it blows up. You can see that by running the test suites of program_options or regex libs as I suggested or write your little program_options test program if you feel like it. What I noticed was that, although I didn't build any shared libs, the auto-import messages were still being displayed when I used the cygwin gcc-4 (when linking against boost for my project). But when I switched to the vanilla gcc 4.x that I had built myself, I saw no such messages naturally, and everything worked as it should. That's why I thought this freeze might be related to the auto-import feature (even though I'm using only static libraries) As I said, if you give the --enable-auto-import option it only causes a more dramatic crash, please read my previous post in which I had requested help with boost-1.39 on cygwin-1.7, to which absolutely no replies came: http://cygwin.com/ml/cygwin/2009-06/msg00799.html The same problems occur exactly on cygwin-1.5. I was at first suspicious that I might be doing something wrong, but having seen that the vanilla gcc works, it is likely that the patches are causing the problem so I thought I should bring this to your attention since the importance of boost is only going to increase. I did notice that the auto-import feature makes some assumptions about the code. Those assumptions may be contradicted by the boost code, but of course you cannot expect any library to conform to a cygwin standard rather than the ISO standard. At any rate, it seems rather strange that linking static libraries fails. May I humbly suggest to the package maintainer that he tries the myriad test suite programs included in boost-1.39 library against gcc-4? And then against a vanilla gcc-4? I'm sorry that I haven't been able to exactly isolate or fix this bug, but at least I can tell you how to reproduce it. I've tried to track down boost/cygwin build problems on the net and superficially it would seem that they have all been resolved but this does not seem to be the case. Many thanks in advance, -- Eray
Re: 1.7 winbase.h (ilockcmpexch) compile error
On Wed, Jun 24, 2009 at 04:37:56PM -0500, Brian Ford wrote: On Wed, 24 Jun 2009, Christopher Faylor wrote: On Wed, Jun 24, 2009 at 07:40:39PM +0100, Dave Korn wrote: Brian Ford wrote: g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) winsup/cygwin/winbase.h: In member function `int pthread_mutex::_trylock(pthread*)': winsup/cygwin/winbase.h:59: warning: volatile register variables don't work as you might wish winsup/cygwin/winbase.h:63: error: can't find a register in class `AREG' while reloading `asm' http://cygwin.com/ml/cygwin-patches/2009-q2/msg00072.html (Haven't used 3.x to build the DLL in ages myself.) I'm comfortable making gcc 4.x a requirement for building Cygwin and its utilities. I'm prepared to work the problem as my time permits, but I assume you are going to get far less help with Cygwin debugging/development if you require a compiler that is not yet in the distribution. (I know you think you get next to no help now, and that this isn't a big issue for those that do contribute, but it still doesn't seem like a very good idea.) http://cygwin.com/packages/gcc4/ http://cygwin.com/packages-2/gcc4/ 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: 1.7 winbase.h (ilockcmpexch) compile error
On Wed, 24 Jun 2009, Christopher Faylor wrote: On Wed, Jun 24, 2009 at 04:37:56PM -0500, Brian Ford wrote: I'm prepared to work the problem as my time permits, but I assume you are going to get far less help with Cygwin debugging/development if you require a compiler that is not yet in the distribution. (I know you think you get next to no help now, and that this isn't a big issue for those that do contribute, but it still doesn't seem like a very good idea.) http://cygwin.com/packages/gcc4/ http://cygwin.com/packages-2/gcc4/ Sorry, I forgot that an experimental package was available. My cygwin mailing list skimming time and abilities have been lacking of late. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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 winbase.h (ilockcmpexch) compile error
On Wed, 24 Jun 2009, Brian Ford wrote: On Wed, 24 Jun 2009, Christopher Faylor wrote: http://cygwin.com/packages/gcc4/ http://cygwin.com/packages-2/gcc4/ Sorry, I forgot that an experimental package was available. My cygwin mailing list skimming time and abilities have been lacking of late. ...and I see now that they aren't even in the setup exp category, and that I already had it installed. Today is not my day for correctness :-(. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- 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
Error trying to cramfsck - mknod issue with sockets?
Hi - I'm trying to extract a cramfs image built from a Linux system under Windows using cygwin. I have a Vista OS and have installed the latest current cygwin build. I'm a windows guy and have little knowledge of Linux. I start up a bash shell and run cramfsck -v -x test rootfs which all goes well until I get: s 0666 0 0:0 test/dev/log cramfsck: mknod failed: test/dev/log: Invalid argument which looks to me like mknod doesn't like creating socket files? Now from what little I can figure out, mknod uses some sort of device table to know what sort of things it can create? and maybe sockets isn't one of them? Can someone please help me to try to figure out what I need to get this working? also, I don't have a /dev/log folder - could that be an issue? Thanks for any help, John _ POP access for Hotmail is here! Click here to find out more http://windowslive.ninemsn.com.au/article.aspx?id=802246 -- 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/sluggish response (system task at 50%)
Larry Hall (Cygwin) wrote: Gene Smith wrote: snip Going back to beta-1.7 default install that ran fast I noticed that it was actually using a mingw32 version of make from winavr project and not the cygwin make. The default cygwin install does not include make. When I load the cygwin make package and the build uses it (since cygwin puts its paths ahead of windows path) the build slows way down. If I remove make from cygwin's /bin it speeds back up (since using the mingw32 make). The build referred to above uses a toolchain built for mingw32, not cygwin's gcc. So as long as make is also built for mingw32 the build is fast when run from cygwin terminal or dos window. With make being the cygwin version, the build is slow in all cases. What does this mean? Am I doing something illegal mixing cygwin and mingw programs? Interesting. I'm not sure why using Cygwin's 'make' would slow things down dramatically when running from a Cygwin terminal or shell. I can see there being some overhead if that's the only Cygwin process you're running, since there would be a Cygwin initialization cost to start 'make' if there were no other Cygwin processes running at the time. I very much doubt that this would account for the dramatic slow-down you've reported. So while certainly there's an issue here, it seems like the work-around you've found is viable. And it does make more sense than mixing and matching Cygwin and Mingw. Are you able to reproduce this problem for any kind of package? It might be helpful to know that building package or tarball 'foo' demonstrates the problem. Larry, Currently I have 3 embedded projects buildable with cygwin. 2 of them are slow with cygwin make and ok with a mingw make (winavr's or codesourcery's cs-make). However, with the 3rd project I see no difference in speed between cs-make clean all and make clean all! This project has no recursive make calls, $(MAKE). But on the other two that have a speed difference, if I try to run cygwin make twice in a row, make clean ; make, I see the error .dep/main.0.d:1 *** multiple target patterns. Stop. I have to rm .dep/* to fix it. (These are generated dependency files.) I think I may have seen a reference to this as a known problem with cygwin's make but don't know if it is related to speed issue in any way. Just thought I would point this out. Also, I might point out that the two projects with speed difference, one has recursive makes while the other does not. -- 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] [1.7] Updated: bind-9.6.0_p1-1
The following packages have been updated for Cygwin 1.7: * bind-9.6.0_p1-1 * libbind9-devel-9.6.0_p1-1 * libbind9_50-9.6.0_p1-1 * libdns-devel-9.6.0_p1-1 * libdns50-9.6.0_p1-1 * libisc-devel-9.6.0_p1-1 * libisc50-9.6.0_p1-1 * libisccc-devel-9.6.0_p1-1 * libisccc50-9.6.0_p1-1 * libisccfg-devel-9.6.0_p1-1 * libisccfg50-9.6.0_p1-1 * liblwres-devel-9.6.0_p1-1 * liblwres50-9.6.0_p1-1 This is an overdue update to ISC BIND. This release is the first built for Cygwin 1.7 and gcc-4.3 with shared libgcc. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/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: Some questions about mintty
At the bash shell prompt while editing commands is one example, but it is also the case for me in text editors, vim or emacs, for example. From the Options menu, I set the cursor type to block and set the cursor color to a light color, say, yellow, and then moved the block cursor back over the text of a command at the shell prompt. Because the cursor-text color remained white, when it combined with the light block color, the text inside the cursor block disappeared. Could you attach your .minttyrc? Have you got any commands in your bash startup files that might be relevant here? And what's you PS1 setting? To simplify the problem, I eliminated the ~/.bashrc ~/.bash_profile initialization files: $ mintty -e /bin/bash --norc --noprofile Please find attached a simplified ~/.minttyrc file. I renamed my old file, started mintty, set the color options for foreground, background, and cursor, set the cursor type to 'block' and then accepted these changes to generate a new ~/.minttyrc file. PS1 is: [~]$ echo $PS1 [\W]\$ The behavior with the block cursor's text remains: The text is light inside the light block, making the character difficult to read. Using the solution that you provided (echoing an escape sequence to set the cursor text color) fixes the problem. Columns=80 Rows=36 Transparency=0 OpaqueWhenFocused=1 Scrollbar=1 ScrollbackLines=1 ConfirmExit=1 WindowShortcuts=1 EditShortcuts=1 ZoomShortcuts=1 BoldAsBright=0 AllowBlinking=0 CursorType=0 CursorBlinks=0 FontIsBold=0 FontHeight=14 FontCharset=0 FontQuality=1 BackspaceSendsDEL=1 EscapeSendsFS=0 AltSendsESC=0 ScrollMod=1 RightClickAction=0 CopyOnSelect=1 ClicksPlaceCursor=0 ClicksTargetApp=1 ClickTargetMod=1 BellType=1 BellIndication=2 Font=Lucida Sans Typewriter Codepage=UTF-8 Printer= ForegroundColour=0,0,0 BackgroundColour=255,255,255 CursorColour=255,255,0 -- 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/sluggish response (system task at 50%)
On Wed, June 24, 2009 17:29, Larry Hall (Cygwin) wrote: Sure, we all know that Cygwin provides Linux emulation and suffers some overhead for it. But timings from an individual machine can be misleading. Running this through multiple times for both Mingw and Cygwin 1.7 on my similarly equipped machine, I see Cygwin is somewhere between 1.7 and 2.25 times slower. Whether yours or my result is more typical, I can't say. But as you noted, neither data set provides much justification for the results reported. Larry, Are you on 32-bit Windows or 64-bit Windows? I've noted on this mailing list earlier that there are large speed differences between the two. I wonder which platform Gene is on. The tr test results are consistent on Windows 64-bit for me. I don't quite understand what MINGW32 is doing that makes it ~2 times faster than cygwin. -Edward -- 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/sluggish response (system task at 50%)
PS. So I went ahead and repeated the tr test on an older (Intel Core 2 Quad 2.66 GHz) machine with cygwin 1.5 on Windows *32-bit*: $ time -p for ((i=1; i100; i++)); do var=$(echo $i | tr [a-z] [A-Z]); done real 2.64 user 6.56 sys 1.85 We're talking about a difference between an Intel processor ONE GENERATION OLDER, on an older version of cygwin, yet being a few times FASTER. On Wed, June 24, 2009 21:49, Edward Lam wrote: On Wed, June 24, 2009 17:29, Larry Hall (Cygwin) wrote: Sure, we all know that Cygwin provides Linux emulation and suffers some overhead for it. But timings from an individual machine can be misleading. Running this through multiple times for both Mingw and Cygwin 1.7 on my similarly equipped machine, I see Cygwin is somewhere between 1.7 and 2.25 times slower. Whether yours or my result is more typical, I can't say. But as you noted, neither data set provides much justification for the results reported. Larry, Are you on 32-bit Windows or 64-bit Windows? I've noted on this mailing list earlier that there are large speed differences between the two. I wonder which platform Gene is on. The tr test results are consistent on Windows 64-bit for me. I don't quite understand what MINGW32 is doing that makes it ~2 times faster than cygwin. -Edward -- 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/sluggish response (system task at 50%)
On Wed, June 24, 2009 21:53, Edward Lam wrote: PS. So I went ahead and repeated the tr test on an older (Intel Core 2 Quad 2.66 GHz) machine with cygwin 1.5 on Windows *32-bit*: Sorry, I got the system specs wrong. It's actually just an Intel Core 2 6600 2.40 GHz machine. $ time -p for ((i=1; i100; i++)); do var=$(echo $i | tr [a-z] [A-Z]); done real 2.64 user 6.56 sys 1.85 We're talking about a difference between an Intel processor ONE GENERATION OLDER, on an older version of cygwin, yet being a few times FASTER. On Wed, June 24, 2009 21:49, Edward Lam wrote: On Wed, June 24, 2009 17:29, Larry Hall (Cygwin) wrote: Sure, we all know that Cygwin provides Linux emulation and suffers some overhead for it. But timings from an individual machine can be misleading. Running this through multiple times for both Mingw and Cygwin 1.7 on my similarly equipped machine, I see Cygwin is somewhere between 1.7 and 2.25 times slower. Whether yours or my result is more typical, I can't say. But as you noted, neither data set provides much justification for the results reported. Larry, Are you on 32-bit Windows or 64-bit Windows? I've noted on this mailing list earlier that there are large speed differences between the two. I wonder which platform Gene is on. The tr test results are consistent on Windows 64-bit for me. I don't quite understand what MINGW32 is doing that makes it ~2 times faster than cygwin. -Edward -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Slow/sluggish response (system task at 50%)
Edward Lam wrote: On Wed, June 24, 2009 17:29, Larry Hall (Cygwin) wrote: Sure, we all know that Cygwin provides Linux emulation and suffers some overhead for it. But timings from an individual machine can be misleading. Running this through multiple times for both Mingw and Cygwin 1.7 on my similarly equipped machine, I see Cygwin is somewhere between 1.7 and 2.25 times slower. Whether yours or my result is more typical, I can't say. But as you noted, neither data set provides much justification for the results reported. Larry, Are you on 32-bit Windows or 64-bit Windows? I've noted on this mailing list earlier that there are large speed differences between the two. I wonder which platform Gene is on. The tr test results are consistent on Windows 64-bit for me. Good point. My test was run against 32-bit Windows. Gene's cygcheck output says he's running 32-bit Windows as well. I don't quite understand what MINGW32 is doing that makes it ~2 times faster than cygwin. It has to do with what it doesn't do. But I think the more interesting issue is what's making things _so_ slow in some of his builds. -- 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? -- 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] Updated: bind-9.6.0_p1-1
The following packages have been updated for Cygwin 1.7: * bind-9.6.0_p1-1 * libbind9-devel-9.6.0_p1-1 * libbind9_50-9.6.0_p1-1 * libdns-devel-9.6.0_p1-1 * libdns50-9.6.0_p1-1 * libisc-devel-9.6.0_p1-1 * libisc50-9.6.0_p1-1 * libisccc-devel-9.6.0_p1-1 * libisccc50-9.6.0_p1-1 * libisccfg-devel-9.6.0_p1-1 * libisccfg50-9.6.0_p1-1 * liblwres-devel-9.6.0_p1-1 * liblwres50-9.6.0_p1-1 This is an overdue update to ISC BIND. This release is the first built for Cygwin 1.7 and gcc-4.3 with shared libgcc. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
