Re: Cygport and auto-manifestize compatibility manifest
On Nov 20 19:14, Corinna Vinschen wrote: On Nov 20 18:32, Corinna Vinschen wrote: On Nov 20 18:22, Achim Gratz wrote: Corinna Vinschen writes: Well, perhaps. I'm just not sure it's the right thing to do it at postinstall time. I mean, it's not impossible, obviously, but it's a lot of stuff per executable and running this for a few thousand .exe files could take some time. Yes, it does... but ever since I've switched to doing incremental autorebases that time has shrunk a lot. We would also have to make sure that the sections with long section names are recreated after adding the .rsrc section, which is something I don't quite see how to accomplish, right now. Hmm. I'm out of my depths on this, but would it be possible to excise those sections, do whatever changes are necessary to the rest of the executable and then add them back? I don't know. It's apparently more complicated than just calling objcopy. For instance, objcopy can export sections from a file in whatever format you want, but it can only add back sections if they are given as binary blobs. If you add such a binary blob it's missing relocation information. Also, you have to make sure all the sections start at the right address, thanks to the harebrained PE/COFF format. This is apparently a big deal, otherwise it should have been no problem to add a resource binary blob into an executable without making Windows choke on it (ERROR_BAD_EXE_FORMAT). Maybe I did something wrong, but I would have no idea what option I missed. I just made a quick test for the sake of creating a generic script to add the manifests. [...] For the records and to all interested in this. I have a script now which works, provided the executables are stripped and the .gnu_debuglink section is the only section with a long section name. The sources of the script called add-mani.sh and the sources of the Windows tool necessary to update the manifest are attached. The downside: If you add a manifest to, say, tcsh, the tcsh.exe.dbg file from the tcsh-debuginfo package will not have the .rsrc section, and due to the Dwarf2 debug sections you will not be able to add the .rsrc section successfully *and* keep the tcsh.exe.dbg file debuggable. This in turn results in a warning in GDB: warning: section .rsrc not found in /usr/lib/debug/bin/tcsh.exe.dbg The tcsh binary is still debuggable, apparently, but still... Therefore I think this script is only a temporary measure, until the time the binutils package allows to accomplish this by itself. We're working on that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat manifestize.tar.xz Description: application/xz pgp4o0mszk0If.pgp Description: PGP signature
src/winsup/cygwin ChangeLog select.cc
CVSROOT:/cvs/src Module name:src Changes by: c...@sourceware.org 2013-12-03 20:28:55 Modified files: winsup/cygwin : ChangeLog select.cc Log message: * select.cc (select): Add workaround for, as yet undebugged, pathological case. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6274r2=1.6275 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/select.cc.diff?cvsroot=srcr1=1.219r2=1.220
src/winsup/lsaauth ChangeLog configure configu ...
CVSROOT:/cvs/src Module name:src Changes by: c...@sourceware.org 2013-12-03 20:51:05 Modified files: winsup/lsaauth : ChangeLog configure configure.ac Log message: * configure.ac: Back out stupid change. * configure: Regenerate. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/ChangeLog.diff?cvsroot=srcr1=1.22r2=1.23 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/configure.diff?cvsroot=srcr1=1.6r2=1.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/configure.ac.diff?cvsroot=srcr1=1.3r2=1.4
Re: chere + mintty doesn't work with mapped drives
On Dec 2 23:58, Charles Butterfield wrote: -Original Message- From: Dave Kilroy [mailto:BZ] http://cygwin.com/acronyms/#PCYMTNQREAIYR On 01/12/2013 21:09, Corinna Vinschen wrote: Are you starting mintty with run as administrator by any chance? Corrina's right - check that the same user is being used in both cases. I don't think this would explain why it's not working from the context menus though. Finding out why bash under mintty doesn't think /cygdrive/y/apps is a directory is the key. SOLVED Yes, I was starting mintty as admin and yes this was the culprit. I was doing this by using a shortcut (similar, but not identical to the installed Cygwin Terminal shortcut), that had the checkbox Compatibility|Run this program as an administrator enabled. I ASSUMED this would only affect mintty when launched from this shortcut. HOWEVER, it seems that this changes a property associated with mintty regardless of how it is launched. Apparently another Wonder of Windows. Unchecking the run as admin fixed the problem associated with accessing the mapped drives everywhere (including the Bash Prompt Here xhere Processing). The reason I was running as admin was that many of the network centric scripts that I use frequently during certain phases of various projects seem to require admin privs and simply fail without any attempt to escalate (which I seem to recall is due to a mismatch between the Windows and Unix Security models). I guess I'll have to rethink that approach. Any suggestions on how to have a shortcut (or something similar) that runs mintty as admin, but has no global effect on other mintty launches? You seem to have gotten something else wrong here. If the shortcut has the run as admin flag, it only affects this shortcut. I have two shortcuts on the desktop, one called Cygwin64 Terminal, the other one Cygwin64 Admin. The second shortcut is a simple copy of the first one, so it starts C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - just like the first. Only the second shortcut has the Run as admin flag set. If I start mintty from the first shell, id prints: uid=11001(corinna) gid=11125(vinschen) groups=11125(vinschen), 559(Performance Log Users),545(Users), 10572(Denied RODC Password Replication Group),10513(Domain Users) If I start mintty from the second shortcut, id prints uid=11001(corinna) gid=11125(vinschen) groups=11125(vinschen), 544(Administrators),559(Performance Log Users),545(Users),!!! 10572(Denied RODC Password Replication Group),10513(Domain Users) And, btw., I created the Admin shortcut just for testing. Otherwise I usually only do a right click on the shortcut and use the Run as administrator entry there. It's much less hassle than creating an extra shortcut for this task. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpeL4X07pbSt.pgp Description: PGP signature
Re: [PATCH] 'rebase' uninitialised variable (was: Cygwin64: Rebase problems)
On Dec 2 21:19, Jason Tishler wrote: Corinna, On Sun, Dec 01, 2013 at 01:23:00PM +0100, Corinna Vinschen wrote: On Nov 30 06:32, David Stacey wrote: Jason Tishler: As rebase maintainer, if you agree with my diagnosis then please could you make new versions of 'rebase' containing the fix for both architectures. Thank you. Jason, do you have time to do that? Otherwise I can create new packages as well (after bumping the version to 4.4.1). I will release a new package for each architecture as soon as possible. Cool, thank you! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSXPlirR6Pd.pgp Description: PGP signature
Re: emacs-x11: new clipboard size limitation?
On Dec 2 14:56, Jon TURNEY wrote: On 02/12/2013 14:17, Corinna Vinschen wrote: On Dec 2 13:11, Jon TURNEY wrote: What you write does seem to support the theory that this is a regression in select() in the cygwin DLL. It might be useful if you could say what version of the cygwin DLL you had when it was working correctly before you upgraded. [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html Are you sure this is a select problem? If so, can you create an STC, perhaps? Only a madman is absolutely sure. I'm afraid the best test case I have a the moment is: Install xorg-server-debuginfo Start XWin -noclipboard -multiwindow Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it Start emacs-x11, open the Shakespeare text from [1] in a buffer Open notepad Copy and paste the text from the emacs buffer into notepad The breakpoint is hit. Notice that select() has returned 0, the read ready fd_set is empty and the timeout hasn't expired. I claim that the read ready fd_set should indicate that the X connection socket is ready. Well, that's not exactly an STC... So, IIUC, you're saying that, in fact, select doesn't return too early, rather it returns without setting the return value correctly. You expect it to return a value 0, right? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTiRhx0yHbh.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated, new for 64-bit: lftp 4.4.11-1
Andrew Schulman schulman.andrew@... writes: A new version of lftp, 4.4.11-1, is available in the Cygwin distribution. The is the first release of lftp for x86_64. This version seems to have serious problems with the mirror command. Instead of transferring just the changed files, it seems to always want to transfer _everything_. I haven't yet looked into why this might happen, at the moment I've reverted to the previous version. Regards, Achim. -- 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-x11: new clipboard size limitation?
On Dec 3 11:31, Corinna Vinschen wrote: On Dec 2 14:56, Jon TURNEY wrote: On 02/12/2013 14:17, Corinna Vinschen wrote: On Dec 2 13:11, Jon TURNEY wrote: What you write does seem to support the theory that this is a regression in select() in the cygwin DLL. It might be useful if you could say what version of the cygwin DLL you had when it was working correctly before you upgraded. [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html Are you sure this is a select problem? If so, can you create an STC, perhaps? Only a madman is absolutely sure. I'm afraid the best test case I have a the moment is: Install xorg-server-debuginfo Start XWin -noclipboard -multiwindow Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it Start emacs-x11, open the Shakespeare text from [1] in a buffer Open notepad Copy and paste the text from the emacs buffer into notepad The breakpoint is hit. Notice that select() has returned 0, the read ready fd_set is empty and the timeout hasn't expired. I claim that the read ready fd_set should indicate that the X connection socket is ready. Well, that's not exactly an STC... So, IIUC, you're saying that, in fact, select doesn't return too early, rather it returns without setting the return value correctly. You expect it to return a value 0, right? I don't see any bigger changes in select since Cygwin 1.7.19. Only one change since then, and that's only in 1.7.26, not in 1.7.25 as the OP claimed using. The change in 1.7.19 is only 64 bit related, changing an unsigned to a size_t cast and a few debug printfs. Only in 1.7.18 is a little bit bigger change but it should only affect signal handling. Talking about wndproc.c, it only checks iReturn for being 0. After that, we don't really know which value it has, we only know that FD_ISSET(iConnNumber, fdsRead) returns 0. The value of iReturn should be printed in the debug output at line 133. What kind of object is the iConnNumber descriptor? Pipe? Fifo? Socket? /dev/windows? We really need a simple testcase without the X and emacs overhead... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGkKlWRA58C.pgp Description: PGP signature
Re: chere + mintty doesn't work with mapped drives
On 03/12/2013 10:21, Corinna Vinschen wrote: On Dec 2 23:58, Charles Butterfield wrote: Any suggestions on how to have a shortcut (or something similar) that runs mintty as admin, but has no global effect on other mintty launches? You seem to have gotten something else wrong here. If the shortcut has the run as admin flag, it only affects this shortcut. I have two shortcuts on the desktop, one called Cygwin64 Terminal, the other one Cygwin64 Admin. I think the difference is where you select the checkbox. There's one in Compatibility-Privilege Level-Run as admin, and another in Shortcut-Advanced-Run as admin. The compatibility one is telling windows that to execute mintty correctly it needs admin privileges, so it always runs mintty this way. The latter is the one that just affects the shortcut. Glad you got to the bottom of this in the end. Dave. -- 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: chere + mintty doesn't work with mapped drives
On Dec 3 13:13, Dave Kilroy wrote: On 03/12/2013 10:21, Corinna Vinschen wrote: On Dec 2 23:58, Charles Butterfield wrote: Any suggestions on how to have a shortcut (or something similar) that runs mintty as admin, but has no global effect on other mintty launches? You seem to have gotten something else wrong here. If the shortcut has the run as admin flag, it only affects this shortcut. I have two shortcuts on the desktop, one called Cygwin64 Terminal, the other one Cygwin64 Admin. I think the difference is where you select the checkbox. There's one in Compatibility-Privilege Level-Run as admin, and another in Shortcut-Advanced-Run as admin. The compatibility one is telling windows that to execute mintty correctly it needs admin privileges, so it always runs mintty this way. The latter is the one that just affects the shortcut. Spot on. I guess that's it. I completely forgot about the run as admin switch in the compatibility tab, only seeing the run as admin switch in the shortcut's advanced settings. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpW_yO7Ey7zR.pgp Description: PGP signature
Re: chere + mintty doesn't work with mapped drives
On Dec 3 14:32, Corinna Vinschen wrote: On Dec 3 13:13, Dave Kilroy wrote: On 03/12/2013 10:21, Corinna Vinschen wrote: On Dec 2 23:58, Charles Butterfield wrote: Any suggestions on how to have a shortcut (or something similar) that runs mintty as admin, but has no global effect on other mintty launches? You seem to have gotten something else wrong here. If the shortcut has the run as admin flag, it only affects this shortcut. I have two shortcuts on the desktop, one called Cygwin64 Terminal, the other one Cygwin64 Admin. I think the difference is where you select the checkbox. There's one in Compatibility-Privilege Level-Run as admin, and another in Shortcut-Advanced-Run as admin. The compatibility one is telling windows that to execute mintty correctly it needs admin privileges, so it always runs mintty this way. The latter is the one that just affects the shortcut. Spot on. I guess that's it. I completely forgot about the run as admin switch in the compatibility tab, only seeing the run as admin switch in the shortcut's advanced settings. ...despite Charles explicitely mentioning the compatibility thingy. Duh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcNKkHmAWHu.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: inetutils-1.9.1-1; NEW: inetutils-server-1.9.1-1
2013/11/15 Charles Wilson: CHANGES (since 1.7-2) o Updated to latest upstream release o Rely on cygport to autogenerate setup.hints o Split package into client and server components. I just tried to install the clients package and got this notification: inetutils-server(1.9.1-1) Common networking clients and servers (servers) Required by: inetutils Why does the clients package require the servers package? Regards, Frank -- 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: inetutils-1.9.1-1; NEW: inetutils-server-1.9.1-1
On 12/3/2013 8:40 AM, Frank Fesevur wrote: 2013/11/15 Charles Wilson: CHANGES (since 1.7-2) o Updated to latest upstream release o Rely on cygport to autogenerate setup.hints o Split package into client and server components. I just tried to install the clients package and got this notification: inetutils-server(1.9.1-1) Common networking clients and servers (servers) Required by: inetutils Why does the clients package require the servers package? Transition. The old (1.7-x) package was monolithic, so the people who *wanted* the server(s) only needed to install the 'inetutils' package itself. If I *didn't* add this requirement to the new inetutils package (which contains only clients), then those users, when upgrading, would lose their server(s) and their system would break. We don't want that. So, what I typically do when I break up a monolithic package, is ensure that for the *first* update cycle after the breakup, all users will still get all the (new) subpackages. For the *next* update cycle, I'll remove those unnecessary requires: statements. (If somebody waits six months to update, misses 1.9-1, then THEY might get a temporarily broken system. But that's just too bad; can't cater to people who don't keep their systems reasonably up to date). -- Chuck -- 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: chere + mintty doesn't work with mapped drives
-Original Message- From: Dave Kilroy [mailto:kilr...@googlemail.com] I think the difference is where you select the checkbox. There's one in Compatibility-Privilege Level-Run as admin, and another in Shortcut-Advanced-Run as admin. The compatibility one is telling windows that to execute mintty correctly it needs admin privileges, so it always runs mintty this way. The latter is the one that just affects the shortcut. Dave. Thanks! I had NO idea there were TWO admin checkboxes. Now I have a solution to both of my problems, and I'm feeling happy again :-) OOPS, I suspect the last comment is tempting fate. :-( Regards -- Charlie
GOLD STAR (was Re: [PATCH] 'rebase' uninitialised variable)
I can't respond to David Stacey's original mail but I think he should get a gold star for persevering and figuring this out: http://cygwin.com/ml/cygwin/2013-11/msg00484.html 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: GOLD STAR (was Re: [PATCH] 'rebase' uninitialised variable)
On Dec 3 10:43, Christopher Faylor wrote: I can't respond to David Stacey's original mail but I think he should get a gold star for persevering and figuring this out: http://cygwin.com/ml/cygwin/2013-11/msg00484.html I agree. I should have thought about this myself. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpneNTK1eOYE.pgp Description: PGP signature
Re: GOLD STAR (was Re: [PATCH] 'rebase' uninitialised variable)
On Tue, Dec 03, 2013 at 05:05:07PM +0100, Corinna Vinschen wrote: On Dec 3 10:43, Christopher Faylor wrote: I can't respond to David Stacey's original mail but I think he should get a gold star for persevering and figuring this out: http://cygwin.com/ml/cygwin/2013-11/msg00484.html I agree. I should have thought about this myself. But, it is your week for WJM so... -- 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: GOLD STAR (was Re: [PATCH] 'rebase' uninitialised variable)
On Dec 3 11:10, Christopher Faylor wrote: On Tue, Dec 03, 2013 at 05:05:07PM +0100, Corinna Vinschen wrote: On Dec 3 10:43, Christopher Faylor wrote: I can't respond to David Stacey's original mail but I think he should get a gold star for persevering and figuring this out: http://cygwin.com/ml/cygwin/2013-11/msg00484.html I agree. I should have thought about this myself. But, it is your week for WJM so... Oh, right, sorry. Er, no, hang on, I'm just mean, so of course I'm NOT sorry, NOT AT ALL. Sorry about that, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgphT8c2FI9dP.pgp Description: PGP signature
Get old fortran executable to update screen
I'm using an executable compiled from a FORTRAN program When I run it from a DOS command line, I get prompts and progress updates (an iteration count that rewrites the line without scrolling the screen upward). I get none of this when I invoke the program from a cygwin bash shell. The output that should have been displayed to the user is in fact captured if I run the unix (cygwin) script command, but no guileful tricks I tried made the prompts and progress updates display in real time. I tried the script command options -f and -c OldFortramProgram.exe. I managed to get around the lack of prompts by memorizing the order of the input required of the user, and that allows the program to proceed. The progress updates would be useful, though (long run times). Thanks for any suggestions. -- 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-x11: new clipboard size limitation?
On 03/12/2013 11:28, Corinna Vinschen wrote: On Dec 3 11:31, Corinna Vinschen wrote: On Dec 2 14:56, Jon TURNEY wrote: On 02/12/2013 14:17, Corinna Vinschen wrote: On Dec 2 13:11, Jon TURNEY wrote: What you write does seem to support the theory that this is a regression in select() in the cygwin DLL. It might be useful if you could say what version of the cygwin DLL you had when it was working correctly before you upgraded. [1] http://cygwin.com/ml/cygwin-xfree/2013-10/msg00031.html [2] http://cygwin.com/ml/cygwin-xfree/2013-11/msg00012.html Are you sure this is a select problem? If so, can you create an STC, perhaps? Only a madman is absolutely sure. I'm afraid the best test case I have a the moment is: Install xorg-server-debuginfo Start XWin -noclipboard -multiwindow Start xwinclip under gdb, and place a breakpoint at wndproc.c:133, and run it Start emacs-x11, open the Shakespeare text from [1] in a buffer Open notepad Copy and paste the text from the emacs buffer into notepad The breakpoint is hit. Notice that select() has returned 0, the read ready fd_set is empty and the timeout hasn't expired. I claim that the read ready fd_set should indicate that the X connection socket is ready. Well, that's not exactly an STC... So, IIUC, you're saying that, in fact, select doesn't return too early, rather it returns without setting the return value correctly. You expect it to return a value 0, right? Yes, I'm expecting it to return 1 with a bit set in the fd_set. I'm not sure what it means to return before the timeout expires with value 0. I don't see any bigger changes in select since Cygwin 1.7.19. Only one change since then, and that's only in 1.7.26, not in 1.7.25 as the OP claimed using. The change in 1.7.19 is only 64 bit related, changing an unsigned to a size_t cast and a few debug printfs. Only in 1.7.18 is a little bit bigger change but it should only affect signal handling. Okay, so I did what I should have done in the first place and tried bisecting through cygwin DLL versions for the past 6 months and they all behave the same way. Tried bisecting through the X server versions for the past 6 months, and it seems that this problem first appears in X server 1.14.3-2 (As an aside, it's probably relevant to the recent discussion, that I can't find the thread for, about how many previous versions we should keep around that it's not possible to do this bisection without 'Secret Knowledge' at the moment) This does contain a few clipboard changes, and in particular it changes the way the messages get processed so we will return to the select() more often (after each stage of the conversion operation), which it looks like it could be incorrect sometimes, but I'd expect this to cause unneeded blocking (waiting in select() for a message which has already been placed on the event queue by XPending() rather than the observed behaviour. Anyhow, I guess I need to look at this some more... Talking about wndproc.c, it only checks iReturn for being 0. After that, we don't really know which value it has, we only know that FD_ISSET(iConnNumber, fdsRead) returns 0. The value of iReturn should be printed in the debug output at line 133. It's 0 when I inspect it with the debugger, but yes, I'll change that. What kind of object is the iConnNumber descriptor? Pipe? Fifo? Socket? /dev/windows? We really need a simple testcase without the X and emacs overhead... It's a socket connected to the X server. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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
32/64 issue building native 32-bit Cygwin from CVS
I'm running into this issue when building winsup/lsaauth. My autoconf foo is weak but it appears the configure.ac wants to use 64-bit mingw tools even on this 32-bit build. There was a similar issue in winsup/utils but recently that was fixed elsewhere and picked up by my very recent 'cvs update'. checking for i686-w64-mingw32-gcc... i686-pc-mingw32-gcc checking for x86_64-w64-mingw32-gcc... no configure: error: no acceptable mingw64 cc found in $PATH configure: error: /oss/src/winsup/lsaauth/configure failed for lsaauth make[1]: *** [configure-target-winsup] Error 1 Makefile:8338: recipe for target 'configure-target-winsup' failed make[1]: Leaving directory '/oss/build' Makefile:833: recipe for target 'all' failed make: *** [all] Error 2 Related question: Are the necessary MINGW_CXX=i686-pc-mingw32-g++ MINGW32_CC=i686-pc-mingw32-gcc supposed to be exported by the global configure/build process or do I have to define and export them manually? I've done the latter because the former doesn't seem to be happening automatically. Thanks for any leads, ..mark -- 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: Get old fortran executable to update screen
Greetings, paul! I'm using an executable compiled from a FORTRAN program When I run it from a DOS command line, I get prompts and progress updates (an iteration count that rewrites the line without scrolling the screen upward). I get none of this when I invoke the program from a cygwin bash shell. I suspect you are saying bash shell where it should be mintty terminal, which may be the actual culprit for your issue. Try running bash directly (it should start in standard Windows console) and repeat your tests. The output that should have been displayed to the user is in fact captured if I run the unix (cygwin) script command, but no guileful tricks I tried made the prompts and progress updates display in real time. I tried the script command options -f and -c OldFortramProgram.exe. I managed to get around the lack of prompts by memorizing the order of the input required of the user, and that allows the program to proceed. The progress updates would be useful, though (long run times). -- WBR, Andrey Repin (anrdae...@yandex.ru) 03.12.2013, 22:45 Sorry for my terrible english... -- 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: 32/64 issue building native 32-bit Cygwin from CVS
On Tue, Dec 03, 2013 at 05:03:56PM +, Mark Geisert wrote: I'm running into this issue when building winsup/lsaauth. My autoconf foo is weak but it appears the configure.ac wants to use 64-bit mingw tools even on this 32-bit build. There was a similar issue in winsup/utils but recently that was fixed elsewhere and picked up by my very recent 'cvs update'. Both versions of the compiler are needed for lsaauth. I don't recal any fixes like this for winsup/utils though. 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
Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
On Tue, Dec 03, 2013 at 04:56:27PM +, Jon TURNEY wrote: Tried bisecting through the X server versions for the past 6 months, and it seems that this problem first appears in X server 1.14.3-2 (As an aside, it's probably relevant to the recent discussion, that I can't find the thread for, about how many previous versions we should keep around that it's not possible to do this bisection without 'Secret Knowledge' at the moment) This does contain a few clipboard changes, and in particular it changes the way the messages get processed so we will return to the select() more often (after each stage of the conversion operation), which it looks like it could be incorrect sometimes, but I'd expect this to cause unneeded blocking (waiting in select() for a message which has already been placed on the event queue by XPending() rather than the observed behaviour. Anyhow, I guess I need to look at this some more... Talking about wndproc.c, it only checks iReturn for being 0. After that, we don't really know which value it has, we only know that FD_ISSET(iConnNumber, fdsRead) returns 0. The value of iReturn should be printed in the debug output at line 133. It's 0 when I inspect it with the debugger, but yes, I'll change that. What kind of object is the iConnNumber descriptor? Pipe? Fifo? Socket? /dev/windows? We really need a simple testcase without the X and emacs overhead... It's a socket connected to the X server. I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. 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
[ANNOUNCEMENT] Updated: rebase-4.4.1-1
New News: === I have updated the version of rebase to 4.4.1-1. The tarballs should be available on a Cygwin mirror near you shortly. The following is the change since the previous release: * Fix uninitialized variable problem as described in: http://cygwin.com/ml/cygwin/2013-11/msg00484.html I would like to thank David Stacey for providing the above change. Old News: === The Cygwin rebase distribution contains four utilities: rebase, rebaseall, peflags, and peflagsall. The first utility is modeled after Microsoft's SDK rebase while the rebaseall utility is a convenient way for users that suffer from the Cygwin rebase problem to rebase their entire system (i.e., all of their DLLs). Please read the README file: /usr/share/doc/rebase/README since it covers requirements, usage, known issues, etc. Standard News: 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. If you have questions or comments, please send them to the Cygwin mailing list. *** 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 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 web address. Jason -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: rebase-4.4.1-1
New News: === I have updated the version of rebase to 4.4.1-1. The tarballs should be available on a Cygwin mirror near you shortly. The following is the change since the previous release: * Fix uninitialized variable problem as described in: http://cygwin.com/ml/cygwin/2013-11/msg00484.html I would like to thank David Stacey for providing the above change. Old News: === The Cygwin rebase distribution contains four utilities: rebase, rebaseall, peflags, and peflagsall. The first utility is modeled after Microsoft's SDK rebase while the rebaseall utility is a convenient way for users that suffer from the Cygwin rebase problem to rebase their entire system (i.e., all of their DLLs). Please read the README file: /usr/share/doc/rebase/README since it covers requirements, usage, known issues, etc. Standard News: 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. If you have questions or comments, please send them to the Cygwin mailing list. *** 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 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 web address. Jason
