Re: gcc4-core PACKAGE BUG
On 13/08/2010 20:29, Corinna Vinschen wrote: On Aug 13 20:31, Dave Korn wrote: On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. Cool, thank you. Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On 08/14/2010 12:17 PM, Dave Korn wrote: Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. No, that would only work for people who haven't downloaded it yet, or who explicitly reinstall. A version bump seems like the best way to ensure it gets picked up without any effort on the user's part. Too bad we don't have anything comparable to yum's presto mode that makes delta downloading easier for simple things like adding an x bit. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: gcc4-core PACKAGE BUG
On 14/08/2010 19:19, Eric Blake wrote: On 08/14/2010 12:17 PM, Dave Korn wrote: Come to think of it, wouldn't it be better to just update 4.3.4-3 in place (i.e. without a version bump)? It seems a bit much to force everyone who's already got it installed to redownload that many megabytes just for the sake of a couple of 'x' bits. No, that would only work for people who haven't downloaded it yet, or who explicitly reinstall. Yes, that's the point. The main motivation for the update at all is to stop setup.exe reporting an error in the postinstall script stage. Anyone who's already got it installed isn't going to be bothered by that and would be inconvenienced by being forced to redownload the whole thing just in order to run a script. A version bump seems like the best way to ensure it gets picked up without any effort on the user's part. Too bad we don't have anything comparable to yum's presto mode that makes delta downloading easier for simple things like adding an x bit. I don't think actually fixing the x bit is that important, it's just the scary-and-offputting-to-noobs setup.exe error that needs fixing. As for the actual script itself, I think that anyone who's already got GCC installed and has been running it probably isn't bothered by the problem. I've had to mention it maybe half a dozen times on the list, but haven't had any new reports in ages. It's simple enough to tell folks to chmod or source it manually. So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. cgf
Re: gcc4-core PACKAGE BUG
On 08/14/2010 01:13 PM, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. My only worry now is if any mirrors will have a stale checksum that doesn't correspond to the new tarball. But I'm convinced that it's worth trying the silent upgrade, now. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: gcc4-core PACKAGE BUG
On Sat, Aug 14, 2010 at 01:15:20PM -0600, Eric Blake wrote: On 08/14/2010 01:13 PM, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. My only worry now is if any mirrors will have a stale checksum that doesn't correspond to the new tarball. But I'm convinced that it's worth trying the silent upgrade, now. That's a good point. Dave, when you make the change, please remove any md5.sum in that directory. That will force the file to be regenerated and upset will do the right thing if it isn't there. cgf
Re: gcc4-core PACKAGE BUG
On Sat, Aug 14, 2010 at 03:20:40PM -0400, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 01:15:20PM -0600, Eric Blake wrote: On 08/14/2010 01:13 PM, Christopher Faylor wrote: On Sat, Aug 14, 2010 at 08:05:00PM +0100, Dave Korn wrote: So I really don't think it's worth the end-user's while in this instance, but I'd like to hear what Corinna and cgf think before I proceed. I'm with you on this, Dave. Your reasonsing seems right to me. I don't normally like to make silent changes to existing packages but in this case it seems like the least intrusive way to fix the problem. I wouldn't even announce the change since that would probably generate some confusion. My only worry now is if any mirrors will have a stale checksum that doesn't correspond to the new tarball. But I'm convinced that it's worth trying the silent upgrade, now. That's a good point. Dave, when you make the change, please remove any md5.sum in that directory. That will force the file to be regenerated and upset will do the right thing if it isn't there. To be clear: that directory == /sourceware/ftp/anonftp/pub/cygwin/release/gcc4/... cgf
Re: [PATCH] inform user if any postinstall script failed to run
On 13 August 2010 12:29, Andy Koppe andy.ko...@gmail.com wrote:
On 12 August 2010 20:42, Christopher Faylor wrote:
@@ -433,7 +433,9 @@
ICON IDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20
LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE
,7,0,258,8,NOT WS_GROUP
- LTEXT The following errors occured executing
postinstall scripts,
I think you still need something like the above describing what is going
on.
Actually, isn't the bold Postinstall script errors heading just
above sufficient for that? Only two lines of text fit below it, ...
+ LTEXT These don't necessarily mean that affected packages
will
+ fail to function properly, but if you do notice
problems
+ please check /var/log/setup.log.full.,
Could this be put on the bottom?
... which I guess is why you suggested that? On second thoughts,
though, I think it does need to go above the errors because it's more
likely to be read there.
So here's another take at the patch, amended as suggested by Corinna.
It now also tweaks the bottom coordinate of the results text box,
because I found it ran into the line above the Back/Next/Cancel
buttons.
Index: postinstallresults.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstallresults.cc,v
retrieving revision 1.1
diff -u -r1.1 postinstallresults.cc
--- postinstallresults.cc 29 Jul 2010 13:09:04 - 1.1
+++ postinstallresults.cc 14 Aug 2010 20:03:58 -
@@ -54,15 +54,6 @@
long
PostInstallResultsPage::OnNext ()
{
- // one or more postinstall scripts failed to run successfully
- // installation may be broken
- MessageBox (NULL,
- You will need to investigate and correct these errors
- before your Cygwin installation will function properly.\n
- Check setup.log for details.,
- ERROR - postinstall scripts failed,
- MB_OK | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST);
-
return IDD_DESKTOP;
}
Index: res.rc
===
RCS file: /cvs/cygwin-apps/setup/res.rc,v
retrieving revision 2.88
diff -u -r2.88 res.rc
--- res.rc 6 Aug 2010 18:56:12 - 2.88
+++ res.rc 14 Aug 2010 20:03:59 -
@@ -433,9 +433,11 @@
ICONIDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20
LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE
,7,0,258,8,NOT WS_GROUP
-LTEXT The following errors occured executing
postinstall scripts,
+LTEXT These do not necessarily mean that affected packages
+will fail to function properly, but please check
+/var/log/setup.log.full and report any problems.,
IDC_STATIC,21,9,239,16,NOT WS_GROUP
-EDITTEXTIDC_POSTINSTALL_EDIT,7,41,303,124,WS_VSCROLL | WS_HSCROLL |
+EDITTEXTIDC_POSTINSTALL_EDIT,7,41,303,112,WS_VSCROLL | WS_HSCROLL |
ES_LEFT | ES_MULTILINE | ES_READONLY | ES_AUTOHSCROLL |
ES_AUTOVSCROLL
Re: [PATCH] inform user if any postinstall script failed to run
On Sat, Aug 14, 2010 at 09:14:54PM +0100, Andy Koppe wrote: So here's another take at the patch, amended as suggested by Corinna. It now also tweaks the bottom coordinate of the results text box, because I found it ran into the line above the Back/Next/Cancel buttons. Ship it! cgf
Missing dependency for Athena libraries
Hi all, I just tried to pull down the Athena widget libraries (xaw and xaw3d) and got an unmet dependency message for libXpm-devel. It's not a big deal, since it offered to add it to my list, but a bit odd (I just clicked on each once... none of the cycling though install/keep/reinstall/etc which might have confused something). Regards, Ryan -- 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: Missing dependency for Athena libraries
On 14 August 2010 12:57, Ryan Johnson wrote: I just tried to pull down the Athena widget libraries (xaw and xaw3d) and got an unmet dependency message for libXpm-devel. It's not a big deal, since it offered to add it to my list, but a bit odd (I just clicked on each once... none of the cycling though install/keep/reinstall/etc which might have confused something). That's the new normal, following a change to setup.exe. Previously, dependencies would have been added instantly when you selected a package. The problem with that was that those dependencies weren't deselected if you changed your mind about a package. Also, it got in the way when you cycled through the package actions to get to 'Uninstall', and sometimes people were surprised about the number of packages being quietly pulled in by their selections. Therefore now the dependencies being added automatically are always listed on the 'Resolve Dependencies' page. Seems the wording on that page still needs some fine-tuning though. I presume it was the 'Unmet Dependencies Found' line that made you think there's a problem? Andy -- 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: Unable to install X on 64-bit Windows 7 Premium
On Tue, Aug 10, 2010 at 15:12, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 10/08/2010 00:19, Bob Kline wrote: I finally had to replace my ancient Windows XP box, and ended up with a Windows 7 Home Premium 64-bit system. If I run setup.exe to install a fresh cygwin, it succeeds as long as I don't touch the X11 set, leaving it at Default (which is to say, don't install anything in the set). If I change Default to Install for X11, I get a dialog box which says: Cygwin Setup - Running postinstall scripts Postinstall script errors The following errors occured executing postinstall scripts Package: gcc4-core gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. chmod 755 /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh and then run /etc/postinstall/gcc4-core.sh manually should work. I've done exactly this, then tried to install some X stuff and got: Package: xinit xinit.sh exit code 8 Package: No package xinit.sh exit code 8 Any help would be appreciated. Thanks, --Dan -- 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 pipe.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-14 11:16:09 Modified files: winsup/cygwin : ChangeLog pipe.cc Log message: * pipe.cc (fhandler_pipe::open): Duplicate content of opened pipe fhandler before calling dup method. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4992r2=1.4993 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pipe.cc.diff?cvsroot=srcr1=1.124r2=1.125
Re: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
On Aug 13 19:11, Pedro Izecksohn wrote: I thought to use (i) of integer, but its glyph does not remember the proverb about Rome. You mean What have the Romans ever done for us? 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: Emacs and DBUS
On 8/12/2010 10:36 PM, nyc4...@aol.com wrote: Hi, Can the Cygwin Emacs maintainer compile an Emacs binary (emacs-X11, emacs-nox, etc) with D-BUS? It appears that the cygdbus-1-3.dll should be able to be available for Cygwin Emacs support. Thanks. Yes, I've just checked that it builds with D-Bus. I'll upload a test release in a few days. BTW, the configure script gives the following warning: D-Bus integration has been tested for GNU/Linux only. So I don't know if it will work. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Broken process substitution
On Aug 13 14:25, Eric Blake wrote: On 08/13/2010 02:17 PM, Eric Blake wrote: On 08/13/2010 02:04 PM, Daniel Colascione wrote: Try echo hello (cat) -- that's supposed to output hello. What makes you think it's supposed to echo hello? That's system specific on what will happen. According to the bash manual, (cat) is evaluated first, and will result in a /dev/fd reference, or a named pipe (it so happens that it is a /dev/fd reference in cygwin). But this pipe is tied to the subprocess, so it only exists as long as the subprocess exists. Then again, cat should exist until something causes the input side of its pipe to declare EOF; so I guess there's no race in this example after all. Rather, it looks like a limitation in cygwin1.dll. I don't know why bash is unable to duplicate the output end of the pipe to the echo process, unless cygwin's /dev/fd handling doesn't work on pipes. I think I found the culprit in Cygwin. The problem occurs in writev. At the start of this function is a test which checks for the original open mode of the file descriptor. If it's O_RDONLY, the writev function errno set to EBADF. However, this doesn't make much sense, afaics. For one thing, if the underlying handle is really only readable, the underlying NtWriteFile function will fail anyway. And, for this pipe problem it seems to be in the way. If I remove this test, I get bash-3.2$ echo hallo (cat) bash-3.2$ hallo [...hangs here until any key is pressed...] bash-3.2$ That's the exact same behaviour as on Linux, afaics. However, I'm not sure just removing the test is really the right solution. I'll have to take a deeper look first. 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: Broken process substitution
On Aug 14 12:32, Corinna Vinschen wrote: On Aug 13 14:25, Eric Blake wrote: On 08/13/2010 02:17 PM, Eric Blake wrote: On 08/13/2010 02:04 PM, Daniel Colascione wrote: Try echo hello (cat) -- that's supposed to output hello. What makes you think it's supposed to echo hello? That's system specific on what will happen. According to the bash manual, (cat) is evaluated first, and will result in a /dev/fd reference, or a named pipe (it so happens that it is a /dev/fd reference in cygwin). But this pipe is tied to the subprocess, so it only exists as long as the subprocess exists. Then again, cat should exist until something causes the input side of its pipe to declare EOF; so I guess there's no race in this example after all. Rather, it looks like a limitation in cygwin1.dll. I don't know why bash is unable to duplicate the output end of the pipe to the echo process, unless cygwin's /dev/fd handling doesn't work on pipes. I think I found the culprit in Cygwin. The problem occurs in writev. At the start of this function is a test which checks for the original open mode of the file descriptor. If it's O_RDONLY, the writev function errno set to EBADF. However, this doesn't make much sense, afaics. For one thing, if the underlying handle is really only readable, the underlying NtWriteFile function will fail anyway. And, for this pipe problem it seems to be in the way. If I remove this test, I get bash-3.2$ echo hallo (cat) bash-3.2$ hallo [...hangs here until any key is pressed...] bash-3.2$ That's the exact same behaviour as on Linux, afaics. However, I'm not sure just removing the test is really the right solution. I'll have to take a deeper look first. Yep, it was another problem. At one point the code missed to copy over information about a file descriptor. I applied a fix to CVS. 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: Cygwin speed difference on multiple cores -vs- single-core?
On 8/13/10, Andy Nicholas wrote: The scripts we're using form the basis of a build system to invoke GCC and an assembler lots of times throughout a directory tree of a few thousand items. You can end up spending all your time chasing include paths that isn't hard to do. to use multi-threaded builds. When running each testing method, the CPUs are barely loaded at all (10%, maybe) and there's almost no I/O that registers. Is the disk light on ? This is almost always an indication of blocking for something. Check task manager page faults for example. Btw, I don't think the issue is I/O. The disk I'm using is an SSD (OCZ Vertex 2) which is fairly fast. But, the results repeat even if I try a regular 7200 RPM hard drive. I should add this to my manifesto against adjectives along with fast snail comments. 7200rpm=720/6 revs-per-second=120rps. This puts rotation time somewhere in millisecond range. Track to track seeks won't subtract from that. Memory of course is in nanosecond range, 1e6 times faster. The issue is likely to be buffering strategies and syncing. Yeah, weird. 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 -- marchy...@gmail.com note new address 2009-12-16: Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)- use this 404-788-1216 (C)- leave message 989-348-4796 (P)- emergency only marchy...@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: hotmail is censoring incoming mail using random criteria beyond my control and often hangs my browser but all my subscriptions are here..., try also marchy...@yahoo.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
libncurses-devel-5.7-18 doesn't create /usr/include/curses.h
Hi all, Getting compile errors about curses.h not found, and sure enough, it's not in /usr/include. After reinstalling libncurses-devel (I already had it), the problem didn't go away so I looked in the postinstall script. The comment at the top says: # This script will create symbolic links in the toplevel include # directory, pointing to files 'hidden' in the ncurses subdirectory. But I can't find anywhere in the script which actually does this for the .h files. Is this change intentional? Ryan -- 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: libncurses-devel-5.7-18 doesn't create /usr/include/curses.h
On Aug 14 14:11, Ryan Johnson wrote: Hi all, Getting compile errors about curses.h not found, and sure enough, it's not in /usr/include. After reinstalling libncurses-devel (I already had it), the problem didn't go away so I looked in the postinstall script. The comment at the top says: # This script will create symbolic links in the toplevel include # directory, pointing to files 'hidden' in the ncurses subdirectory. But I can't find anywhere in the script which actually does this for the .h files. Is this change intentional? Yes, see http://cygwin.com/ml/cygwin-announce/2010-01/msg2.html 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
bash_completion
Hello, I just updated to cygwin 1.7.5 and I now see some strangeness
with bash completion. When I execute the command ls TAB I see the
following:
[myprompt: etc]$ ls
' xspeccompgen -d -- $quoted | {
while read -r tmp; do
# TODO: I have removed a [ -n $tmp ] before 'printf ..',
# and everything works again. If this bug suddenly
# appears again (i.e. cd /bTAB becomes cd /),
# remember to check for other similar conditionals (here
# and _filedir_xspec()). --David
printf '%s
' $tmp
done
}
))compgen -f -X $xspec -- $quoted
))
Has anyone else run into this?
Regards,
Russell
--
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: experimental package: gcc4-4.5.0-1
Dave, A full release of GCC-4.5.1 will follow shortly. just for completeness, now that you are working on GCC-4.5.1, perhaps you have some comments on this: http://cygwin.com/ml/cygwin-xfree/2010-08/msg5.html Thanks, Angelo. -- 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: Mode dependent cursor shape lost in cygwin Vim in a Windows console
On 13 August 2010 22:30, JOHNER Jean 066030 wrote: No, but I'm sure a patch implementing the DECSCUSR control sequence using SetConsoleCursorInfo() would be welcome. (Copyright assignment required.) I guess this patch is not in Vim code (which is able to do the job in a normal cmd console window) but rather in cygwin.dll which reconfigures the console. Correct. Theoretically this could be patched into Cygwin vim, but the whole point of Cygwin is that Unix/Linux programs can be compiled and run (nearly) unmodified, so that's not going to happen. Could you implement such a patch yourself? No. I don't maintain the console and mintty keeps me busy enough already. 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: experimental package: gcc4-4.5.0-1
On 14 August 2010 16:47, Angelo Graziosi wrote: Dave, A full release of GCC-4.5.1 will follow shortly. just for completeness, now that you are working on GCC-4.5.1, perhaps you have some comments on this: http://cygwin.com/ml/cygwin-xfree/2010-08/msg5.html Oi, no thread hijacking please. That issue isn't even anything to do with gcc, because byteorder.h is part of the cygwin base package. 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: Mode dependent cursor shape lost in cygwin Vim in a Windows console
On Sat, Aug 14, 2010 at 06:30:50PM +0100, Andy Koppe wrote: Could you implement such a patch yourself? No. I don't maintain the console and mintty keeps me busy enough already. And also: HJM. 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: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
--- I wrote: The x glyph represents the different ways to represent the same number: ... I thought to use (i) of integer, but its glyph does not remember the proverb about Rome. --- Corinna Vinschen asked: You mean What have the Romans ever done for us? All roads lead to Rome. Answering the question asked by Eric Blake: Why do you need these macros? Binary endianness conversion is faster than ASCII conversion. -- 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
