Re: bash.exe.stackdump generated using cygwin 1.7.15
On May 21 14:50, Eric Blake wrote: > On 05/21/2012 10:42 AM, Corinna Vinschen wrote: > > >> The crash occurs after echo exited, so bash wakes up from the wait4 > >> call. However, the problem is that the crash does not occur in Cygwin, > >> but in bash itself. > >> > >> 147 350775 [main] bash 3548 wait4: 2320 = wait4(-1, 0x0, 0, 0x0) > >> --- Process 3548, exception C005 at 00422B0A > >> > >> Eric, can you reproduce this and see where it happens? I'm pretty sure > >> it's a bug in Cygwin, not in bash, but it would be interesting to learn > >> what bash did at the time the crash happened. > > > > Incidentally I built bash without -O2 option for better debugging and > > the problem vanished. Then I built bash again with default optimization > > and the crash still didn't occur. I built from the latest bash src > > package.4.1.10-4 using cygport. > > Uggh. This sounds familiar to another bash bug that I investigated some > time ago, where bash was abusing longjmp() and miscompiled under -O2 but > compiled correctly at -O0 due to the undefined behavior from that abuse, > but I just verified that my patch from back then is still present in my > latest build of bash for cygwin. I'll have to find more time to look > into this. > https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00060.html In my testing it doesn't matter if I build execute_cmd.c or, FWIW, any of bash's source files with -O0, -O1, or -O2. My self-built bash never crashes in this scenario. 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.15-1: mintty bash failing to run .NET executables ?
On May 22 08:22, Pawel Jasinski wrote: Please, don't http://cygwin.com/acronyms/#TOFU > hi, > > roll back your cygwin.dll to 1.7.14-2 Or better, please try the latest developer snapshot from http://cygwin.com/snapshots/ 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: Problem accessing Win98 network drive when logged in via ssh (or cron)
> On May 15 13:29, Gareth Howell wrote: >> Hi >> I have cygwin (latest) running on an XP machine. It needs to access two >> workstations running Win95 and one running Win98. >> >> At the windows level, there are drive maps to the 'C' drives on the three >> workstations as X:, Y: and Z: and the filesystem can be seen. >> Cygwin's fstab has lines to mount the same network shares (using UNC paths) >> under the /mnt directory. >> >> The two Win95 shares and the single Win98 share show up just fine as type >> vfat when I do a mount when running cygwin terminal on the XP machine. >> If I log in remotely using ssh (as Administrator), the two Win95 shares show >> up as before, but the Win98 share shows up as type unknown and I can't >> access the filesystem. The same occurs if a job is run using the >> Administrator's crontab. >> >> I can see it's probably a permissions issue, but I can't get to the bottom >> of it or understand why the behaviour is different between Win95 and Win98. >> >> Any guidance would be welcome. > > First, please read the User's Guide chapter about switching the user > context. It explains the problems with mapping shares when changing > the user account via ssh or whatever: > http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview > > In your scenario it might have something to do with the way the shares > are shared. The old SMB knew user level shares and, well, share level > shares. The latter doesn't require a logon to be accessible. Maybe the > 95 shares are shared this way? > > > 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 > Thanks for that Corinna. It's weird; the Win95 shares appear OK, it's only the Win98 share. As I indicated in another thread, I have avoided the problem by using a different workstation as the proxy. I have a different problem with that one though. All three shares appear OK when I log in using SSH. When I try to run rsync over ssh though, I get errors saying the mount points "vanished" during the transfer. Gareth -- 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.15-1: pthread_cancel and pthread_kill not working as expected
Hi Otto, On May 21 14:44, Otto Meta wrote: > > Would you mind to provide *simple* testcases to allow easy debugging > > of your observations? > > I reduced the various tests to three rather simple individual testcases > because those show possibly different bugs. Thanks! > Testcase cancel deferred: > Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1 > and 1.7.15-1. If that works in the snapshot anyway, I'm not going to look into that one. > Testcase cancel asynchronous: > Async cancel seems to have no effect with any tested version. I think I found a solution for this problem. See the comment in the patch at http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=src&r1=1.258&r2=1.259 Please test the today's developer snapshot. > Testcase signal/kill: > Signals may or may not reach the correct thread with 1.7.12-1 and newer. Confirmed. I think the reason is that we only have a single event to signal that a POSIX signal arrived instead of a per-thread event, but I'm not sure. This is cgf's domain so I leave it at that for now. 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 -nw" hangs in a terminal
On May 21 14:51, Ken Brown wrote: > On 5/21/2012 12:29 PM, Corinna Vinschen wrote: > >On May 21 11:31, Ken Brown wrote: > >>On 5/21/2012 6:02 AM, Ken Brown wrote: > >>>On 5/21/2012 4:50 AM, Filipp Gunbin wrote: > emacs-24.0.96-2 crashes when I am doing the following: > > 1) emacs -Q -nw > 2) M-x shell > 3) C-x C-f C-g > >>> > >>>I can reproduce this. I'll try again to fix it. > >> > >>I've discovered something strange by running emacs under gdb. If I > >>start emacs-24 in a terminal (but not under X) and start a shell as > >>you did, then every press of C-g creates a new thread, and these are > >>never destroyed. I'm pretty sure the threads are created by Cygwin, > >>not by emacs. > > > >What does C-g mean in Emacs? What's it supposed to do? Does it > >call select or poll? > > It's supposed to quit whatever operation is in progress. It doesn't > call select or poll. In the situation of Filipp's instructions > above, C-x C-f has caused emacs to prompt for a file name, and C-g > should interrupt that. It also rings the the terminal bell and > prints "Quit" in the echo area at the bottom of the screen. > > The situation in my instructions is slightly different. Prior to > the user pressing C-g, emacs is running its idle loop, in which it > repeatedly calls select to see if there's any event it needs to > respond to. When C-g is pressed, select returns and emacs reacts > to the keypress. In this case there's nothing to do but ring the > terminal bell and print "Quit". Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I try it under Cygwin 1.7.15 or current 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: "emacs -nw" hangs in a terminal
On 5/22/2012 7:28 AM, Corinna Vinschen wrote: On May 21 14:51, Ken Brown wrote: On 5/21/2012 12:29 PM, Corinna Vinschen wrote: On May 21 11:31, Ken Brown wrote: On 5/21/2012 6:02 AM, Ken Brown wrote: On 5/21/2012 4:50 AM, Filipp Gunbin wrote: emacs-24.0.96-2 crashes when I am doing the following: 1) emacs -Q -nw 2) M-x shell 3) C-x C-f C-g I can reproduce this. I'll try again to fix it. I've discovered something strange by running emacs under gdb. If I start emacs-24 in a terminal (but not under X) and start a shell as you did, then every press of C-g creates a new thread, and these are never destroyed. I'm pretty sure the threads are created by Cygwin, not by emacs. What does C-g mean in Emacs? What's it supposed to do? Does it call select or poll? It's supposed to quit whatever operation is in progress. It doesn't call select or poll. In the situation of Filipp's instructions above, C-x C-f has caused emacs to prompt for a file name, and C-g should interrupt that. It also rings the the terminal bell and prints "Quit" in the echo area at the bottom of the screen. The situation in my instructions is slightly different. Prior to the user pressing C-g, emacs is running its idle loop, in which it repeatedly calls select to see if there's any event it needs to respond to. When C-g is pressed, select returns and emacs reacts to the keypress. In this case there's nothing to do but ring the terminal bell and print "Quit". Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I try it under Cygwin 1.7.15 or current CVS. That's strange. All my tests were done in mintty. Would it help if I sent some strace output and/or a gdb backtrace? I assumed you could get those (or at least the strace output) yourself, and I didn't want to spam the list. Ken P.S. BTW, I tested today's snapshot, and the problem is still there. -- 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.15-1: pthread_cancel and pthread_kill not working as expected
>> Testcase cancel deferred:
>> Works with 1.7.9 and 20120517 snapshot, fails (hangs) with 1.7.12-1
>> and 1.7.15-1.
> If that works in the snapshot anyway, I'm not going to look into that
> one.
It worked in the reduced testcase with sem_wait(). With read() it’s
still half-broken. See below.
>> Testcase cancel asynchronous:
>> Async cancel seems to have no effect with any tested version.
> I think I found a solution for this problem. See the comment in the
> patch at
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=src&r1=1.258&r2=1.259
> Please test the today's developer snapshot.
Asynchronous cancel seems to work as well as deferred cancel now. Thanks.
Both cancel types work with sem_wait() and pause() now, but for threads
blocked in read() they’re still unreliable. Only one of three blocked
threads is killed in the attached updated testcases.
>> Testcase signal/kill:
>> Signals may or may not reach the correct thread with 1.7.12-1 and newer.
> Confirmed. [...] This is cgf's domain so I leave it at that for now.
Okay, I’ll hope for him to respond then.
Otto
#include
#include
#include
#include
#include
#include
pthread_t tids[3];
static void cleanup_handler(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}
static void* simplethread(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);
char buffer[1] __attribute((unused));
pthread_cleanup_push(&cleanup_handler, intptr);
int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
fprintf(stderr, "Changing canceltype from %i to %i\n", oldtype, PTHREAD_CANCEL_ASYNCHRONOUS);
while (1) {
if (read(STDIN_FILENO, buffer, 1) <= 0) {
fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
*intptr, strerror(errno), self);
} else {
fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
}
pthread_cleanup_pop(1);
return NULL;
}
int main() {
fprintf(stderr, "Testing asynchronous pthread_cancel()\n\n");
int i;
int result;
for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
fprintf(stderr, "Can't create thread: %s\n", strerror(result));
return 1;
}
}
sleep(1);
fprintf(stderr, "\n");
int mainint = 42;
pthread_cleanup_push(&cleanup_handler, &mainint);
for (i=2; i>=0; i--) {
fprintf(stderr, "Cancelling thread %i (%p)\n", i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
fprintf(stderr, "Error during pthread_cancel: %s\n", strerror(result));
}
sleep(1);
}
fprintf(stderr, "\n");
for (i=0; i<3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
fprintf(stderr, "Thread %i is still there (%p)\n", i, tids[i]);
} else {
fprintf(stderr, "Thread %i is gone (%p)\n", i, tids[i]);
}
}
pthread_cleanup_pop(0);
return 0;
}
#include
#include
#include
#include
#include
#include
pthread_t tids[3];
static void cleanup_handler(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, "Thread %i exiting (%p)\n", *intptr, self);
}
static void* simplethread(void *arg) {
int *intptr = (int*)arg;
pthread_t self = pthread_self();
fprintf(stderr, "Thread %i starting (%p)\n", *intptr, self);
char buffer[1] __attribute((unused));
pthread_cleanup_push(&cleanup_handler, intptr);
while (1) {
if (read(STDIN_FILENO, buffer, 1) <= 0) {
fprintf(stderr, "Thread %i encountered an error: %s (%p)\n",
*intptr, strerror(errno), self);
} else {
fprintf(stderr, "Thread %i woke up just fine\n", *intptr);
}
}
pthread_cleanup_pop(1);
return NULL;
}
int main() {
fprintf(stderr, "Testing deferred pthread_cancel()\n\n");
int i;
int result;
for (i=0; i<3; i++) {
int *intptr = (int*)malloc(sizeof(int));
*intptr = i;
result = pthread_create(tids+i, NULL, &simplethread, intptr);
if (result != 0) {
fprintf(stderr, "Can't create thread: %s\n", strerror(result));
return 1;
}
}
sleep(1);
fprintf(stderr, "\n");
int mainint = 42;
pthread_cleanup_push(&cleanup_handler, &mainint);
for (i=2; i>=0; i--) {
fprintf(stderr, "Cancelling thread %i (%p)\n", i, tids[i]);
result = pthread_cancel(tids[i]);
if (result != 0) {
fprintf(stderr, "Error during pthread_cancel: %s\n", strerror(result));
}
sleep(1);
}
fprintf(stderr, "\n");
for (i=0; i<3; i++) {
result = pthread_kill(tids[i], 0);
if (result == 0) {
fprintf(stderr, "Thread %i is still there (%p)\n", i, tids[i]);
} else {
fprintf(stderr, "Thread %i is gone (%p)\n", i, tids[i]);
}
}
pthread_cleanup_pop(0);
return 0;
}
[ANNOUNCEMENT] New package: nmh-1.5-1
Version 1.5-1 of "nmh" has been uploaded. nmh is a capable mail handling system with a command line interface. It consists of simple, single-purpose programs for sending, receiving, saving, retrieving, and otherwise manipulating email messages. You can freely intersperse nmh commands with other shell commands or write custom scripts which utilize nmh commands. If you want to use nmh as a true email user agent, you'll want to also install xmh to provide a user interface for it--nmh only has a command line interface. nmh is configured on Cygwin to use less and vim by default but options allow use of more and emacs, respectively. nmh includes a comprehensive set of man pages. "man nmh" is a good starting point. Please submit bug reports to nmh-work...@nongnu.org. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com 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: "emacs -nw" hangs in a terminal
On May 22 07:42, Ken Brown wrote: > On 5/22/2012 7:28 AM, Corinna Vinschen wrote: > >On May 21 14:51, Ken Brown wrote: > >>On 5/21/2012 12:29 PM, Corinna Vinschen wrote: > >>>On May 21 11:31, Ken Brown wrote: > On 5/21/2012 6:02 AM, Ken Brown wrote: > I've discovered something strange by running emacs under gdb. If I > start emacs-24 in a terminal (but not under X) and start a shell as > you did, then every press of C-g creates a new thread, and these are > never destroyed. I'm pretty sure the threads are created by Cygwin, > not by emacs. > >>>[...] > >Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd > >or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I > >try it under Cygwin 1.7.15 or current CVS. > > That's strange. All my tests were done in mintty. Would it help if > I sent some strace output and/or a gdb backtrace? I assumed you > could get those (or at least the strace output) yourself, and I > didn't want to spam the list. > > Ken > > P.S. BTW, I tested today's snapshot, and the problem is still there. I doubt that an strace is sufficient, but you could send me one created with the latest snapshot off-list, to the address I'm using in the Changelogs. Please point out the places which seem suspicious to you. 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 -nw" hangs in a terminal
On May 22 15:41, Corinna Vinschen wrote: > On May 22 07:42, Ken Brown wrote: > > On 5/22/2012 7:28 AM, Corinna Vinschen wrote: > > >On May 21 14:51, Ken Brown wrote: > > >>On 5/21/2012 12:29 PM, Corinna Vinschen wrote: > > >>>On May 21 11:31, Ken Brown wrote: > > On 5/21/2012 6:02 AM, Ken Brown wrote: > > I've discovered something strange by running emacs under gdb. If I > > start emacs-24 in a terminal (but not under X) and start a shell as > > you did, then every press of C-g creates a new thread, and these are > > never destroyed. I'm pretty sure the threads are created by Cygwin, > > not by emacs. > > >>>[...] > > >Somehow I'm not able to test this. When I start `emacs -Q -nw' in cmd > > >or mintty, emacs takes 100% CPU for some reason. It doesn't matter if I > > >try it under Cygwin 1.7.15 or current CVS. > > > > That's strange. All my tests were done in mintty. Would it help if > > I sent some strace output and/or a gdb backtrace? I assumed you > > could get those (or at least the strace output) yourself, and I > > didn't want to spam the list. > > > > Ken > > > > P.S. BTW, I tested today's snapshot, and the problem is still there. > > I doubt that an strace is sufficient, but you could send me one created > with the latest snapshot off-list, to the address I'm using in the > Changelogs. Please point out the places which seem suspicious to you. Ouch! Hang on. I didn't test with the 24.x version, but with the old one. Sorry about that. Now I can reproduce the SEGV. 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: Bug in package: nc6-1.0-1
On 5/21/2012 9:38 AM, Corinna Vinschen wrote: I'll check in a fix to Cygwin shortly. Please give the next developer snapshot a try. It works fine with 1.7.16s(0.261/5/3) 20120522 12:32:26. It shows an extra message (on both sides), but maybe that is normal for nc6: $ nc6 -4lup 7000 nc6: using datagram socket ... -- René Berber -- 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.15-1: mintty bash failing to run .NET executables ?
> -Original Message- > Sent: Tuesday, May 22, 2012 06:14 > Subject: 1.7.15-1: mintty bash failing to run .NET executables ? > > After that, .NET programs failed to launch at all. The mintty bash terminal just > sits there, no CPU or anything else being used, the .NET .exe failing to launch > according to Task Manager. (Have left it 10 or 15 minutes to make > sure.) Ctrl-C / Ctrl-Break, Ctrl-Z fail to have any effect. Clicking the close 'X' on > the window housing the mintty terminal just kills it (mintty.exe and > bash.exe) immediately (as seen in Task Manager) without comment or > question from Windows. I had the same problem with 1.7.15, and so did one or two other people. The latest developer snapshot fixed the problem for me (so far!). > roll back your cygwin.dll to 1.7.14-2 I would not suggest doing this. The last several Cygwin versions had a series of problems with handling of standard input/output for non-Cygwin programs; in some situations, the problems were timing-sensitive and did not occur 100% of the time. I would also strongly recommend that you look at setting the new pipe_byte option in the CYGWIN environment variable ( http://cygwin.com/cygwin-ug-net/using-cygwinenv.html ). Unfortunately the documentation has zero indication of why you would need to set this, but to summarize, you will probably want/need to set this if you are redirecting standard input to a non-Cygwin program (either .NET or otherwise). You may find it useful to read some of the archived discussion in the Cygwin mailing list over the past few months; there are several discussions regarding these issues that should give you a deeper understanding of the problems. -- 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.15: Cygwin DLL issue with procps and java
Using the snapshot from 2012-05-22 still did not fix 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: SIGINT not passed to java process
Since apparently nobody wants to take ownership of this regression I'll point out the workaround, for the benefit of those googling and landing on this thread: start Java with -Xrs and use Ctrl-Break instead of Ctrl-C. This will disable thread dump and break any application that relies on normal signal handling, though. -- O.L. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012
What is a better way I can give context (and credit) when I am responding to a message, without implying that I expect a reply from the original author? I've been a Usenet user since 1988, and I've never heard of the convention of "quoting implies request for reply". Replies from the original author are always welcome, but I don't necessarily expect them. Maybe I just missed the memo On the receiving side, if I didn't want to respond to a Usenet message, I just didn't. If I wasn't interested in a thread anymore, I just stopped reading it, or put it in my "kill" file. I read the Cygwin mailing list using the gmane.org newsfeed, too. But I was told that replying via my newsreader (Outlook Newsreader) messes up the e'mail threading. So now I subscribe to the digest as well, so that I can reply to the SMTP e'mail instead of replying to the gmane NNTP post. -- 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
64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
> From: Cygwin-L On Behalf Of Warren Young > > I would say that the vast majority of the packages in the Cygwin > distribution could not reasonably make use of 64-bit data spaces. > > However, one of your arguments in this thread cuts both ways: the fact > that there are a few packages that reasonably can do so means you cannot > say "we don't need it". If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits.
Re: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 22/05/2012 20:06, Matt Seitz (matseitz) wrote: >> From: Cygwin-L On Behalf Of Warren Young >> I would say that the vast majority of the packages in the Cygwin >> distribution could not reasonably make use of 64-bit data spaces. >> >> However, one of your arguments in this thread cuts both ways: the fact >> that there are a few packages that reasonably can do so means you cannot >> say "we don't need it". > > If someone wants a 64-bit version of a packages in the distribution, then how > about they build a 64-bit version of the package and report the results? > That would give the distribution maintainers actual data about the costs and > benefits. Hear hear. Well said. Perhaps we can drop this tedious thread now, or else TITTTL. IMHO it has shown rather lamentable knowledge of both compiler technology and RISC/CISC architecture from at least one responder. -- Cliff -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
On 5/22/2012 9:06 PM, Matt Seitz (matseitz) wrote: From: Cygwin-L On Behalf Of Warren Young I would say that the vast majority of the packages in the Cygwin distribution could not reasonably make use of 64-bit data spaces. However, one of your arguments in this thread cuts both ways: the fact that there are a few packages that reasonably can do so means you cannot say "we don't need it". If someone wants a 64-bit version of a packages in the distribution, then how about they build a 64-bit version of the package and report the results? That would give the distribution maintainers actual data about the costs and benefits. Could you please stop this discussion ? Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit cygwin program is pure academic and not very useful. If you want to propose patches for 64 bit cygwin cygwin-developers is the right mailing list. Regards Marco -- 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: 64-bit Cygwin packages (was RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012)
> From: Cygwin-L: On Behalf > Of marco atzeri > > Until we work and deploy a 64bit cygwin1.dll the idea to build any 64 bit > cygwin program is pure academic and not very useful. > > If you want to propose patches for 64 bit cygwin cygwin-developers is the > right mailing list. Sorry if I wasn't clear. That's exactly what I was trying to suggest: if someone wants a 64-bit Cygwin package, they should start by building such a package themselves, including any necessary changes to cygwin1.dll. Once you've got a working example, bring your results and patches to the maintainers.
[ANNOUNCEMENT] Updated: pcre-8.30-1
The following packages have been updated for the Cygwin distribution: *** pcre-8.30-1 *** libpcre1-8.30-1 *** libpcre16_0-8.30-1 *** libpcrecpp0-8.30-1 *** libpcreposix0-8.30-1 *** libpcre-devel-8.30-1 The PCRE library implements regular expression pattern matching using the same syntax and semantics as Perl. This release includes the following notable changes: * Some deprecated functions have been removed from libpcre, whose ABI version was changed accordingly. * A UTF-16 version of the PCRE API is now provided by libpcre16. -- Yaakov Cygwin/X 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
[ANNOUNCEMENT] Updated: audiofile-0.3.4-1
The following packages have been updated for the Cygwin distribution: *** audiofile-0.3.4-1 *** libaudiofile1-0.3.4-1 *** libaudiofile-devel-0.3.4-1 The Audio File Library provides a uniform programming interface for processing of audio data to and from audio files of many common formats (currently AIFF, AIFF-C, WAVE, NeXT/Sun .snd/.au, IRCAM, AVR, Amiga IFF/8SVX, and NIST SPHERE). This is an update to the latest upstream release. The ABI version was bumped, and all current packages which depend on libaudiofile have been rebuilt accordingly. -- Yaakov Cygwin/X 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
[ANNOUNCEMENT] Updated: python-numpy-1.6.2-1
The following package has been updated for the Cygwin distribution: *** python-numpy-1.6.2-1 The NumPy module contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++ and Fortran code, and useful linear algebra, Fourier transform, and random number capabilities. It derives from the old Numeric code base and can be used as a replacement for Numeric. It also adds the features introduced by numarray and can be used to replace numarray. This is an update to the latest upstream release. -- Yaakov Cygwin/X 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
[ANNOUNCEMENT] Updated: apache2-2.2.22-3
The following packages have been updated for the Cygwin distribution: *** apache2-2.2.22-3 *** apache2-devel-2.2.22-3 *** apache2-manual-2.2.22-3 The Apache HTTP Server is a robust, commercial-grade, featureful, extensible, and freely-available source code implementation of an HTTP (Web) server. This release has been rebuilt for pcre-8.30. -- Yaakov Cygwin/X 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: Updated: python-numpy-1.6.2-1
thanks -Original Message- From: cygwin-announce-ow...@cygwin.com [mailto:cygwin-announce-ow...@cygwin.com] On Behalf Of Yaakov (Cygwin/X) Sent: Tuesday, May 22, 2012 3:25 PM To: cygwin-annou...@cygwin.com Subject: Updated: python-numpy-1.6.2-1 The following package has been updated for the Cygwin distribution: *** python-numpy-1.6.2-1 The NumPy module contains a powerful N-dimensional array object, sophisticated (broadcasting) functions, tools for integrating C/C++ and Fortran code, and useful linear algebra, Fourier transform, and random number capabilities. It derives from the old Numeric code base and can be used as a replacement for Numeric. It also adds the features introduced by numarray and can be used to replace numarray. This is an update to the latest upstream release. -- Yaakov Cygwin/X 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
