2.6.x: broken compatibility with Wine
Hi, this issue has been reported 2 month ago [1]. Since MinGW-w64/MSYS2 on Wine is still totally broken and Cygwin is a regression trigger, I'm starting here a thread to track the progress. Qian Hong (fracting) shared an excerpt from IRC-log [2] with some details. Corinna suggested to revert ffcef70. But this didn't happen. I'd like to kindly ask about current considerations towards fixing the lost compatibility. Thanks, Andrey [1] mintty doesn't start under wine-staging https://github.com/Alexpux/MSYS2-packages/issues/682 [2] IRC-log cut https://github.com/Alexpux/MSYS2-packages/issues/682#issuecomment-247065973 P.S. Was it not too early to remove WinXP support? Though it is officially not supported anymore, there are still PCs running WinXP (and Wine). Also there are still systems, I've heard, using some embedded Windows, that shares the same code with WinXP, thus making it not yet truly obsolete. Additionally a lot of work has been done by Cygwin contributors to support this OS and I believe the most of bugs have been workarounded, while due to stopped development it is not likely one has to spend time solving new problems. So was it really worth to drop the hardly crafted code? Are there already some worthwhile advantages? Why wasn't it possible to switch Cygwin WinXP support to just "not officially supported"? (kindly asking) -- 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
issetugid - not declared when _XOPEN_SOURCE is also defined
The following program demonstrates the issue. Should issetugid be declared with this scenario? /*/ #define _XOPEN_SOURCE 1 /* Causes declare warning */ #define __BSD_VISIBLE 1 #include int main(int argc, char ** argv) { int result; result = issetugid(); } // -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]
On 11/9/2016 7:59 AM, Andrey Gursky wrote: > > P.S. Was it not too early to remove WinXP support? Though it is > officially not supported anymore, there are still PCs running WinXP > (and Wine). Also there are still systems, I've heard, using some > embedded Windows, that shares the same code with WinXP, thus making it > not yet truly obsolete. Additionally a lot of work has been done by > Cygwin contributors to support this OS and I believe the most of bugs > have been workarounded, while due to stopped development it is not > likely one has to spend time solving new problems. So was it really > worth to drop the hardly crafted code? Are there already some > worthwhile advantages? Why wasn't it possible to switch Cygwin WinXP > support to just "not officially supported"? (kindly asking) > This has been answered. The problem with supporting XP into infinitude is that every application would need to agree to do the same. Improvements to the OS API would not be able to be used so there are trade-offs for the continued support of an OS that is no longer supported. The code becomes unwieldy to maintain because a change needs to be tested on other systems. Security maintenance becomes impossible because the OS vendor no longer supports the older OS. There is the cygwin time machine, USE IT if you need old software for old OS. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: issetugid - not declared when _XOPEN_SOURCE is also defined
On 11/9/2016 1:13 PM, cyg Simple wrote: > The following program demonstrates the issue. Should issetugid be > declared with this scenario? > > /*/ > #define _XOPEN_SOURCE 1 /* Causes declare warning */ > #define __BSD_VISIBLE 1 > #include > > int main(int argc, char ** argv) { > int result; > result = issetugid(); > } > // > Because when _XOPEN_SOURCE is 1 _DEFAULT_SOURCE doesn't get set which then #undef __BSD_VISIBLE and and sets it to 0. See /usr/include/sys/features.h. If I #define _DEFAULT_SOURCE 1 before the #include then the above code works. However, should it? -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] fish 2.4.0-1
fish 2.4.0-1 is now available in Cygwin. This is a new upstream release, with lots of fixes and improvements, a few of which are incompatible with previous releases. See https://fishshell.com/release_notes.html for the list. fish is the friendly interactive shell. It's a Unix shell that focuses on interactive use, discoverability, and user friendliness. The design goal of fish is to give the user a rich set of powerful features in a way that is easy to discover, remember, and use. Home page: http://fishshell.com Andrew E. Schulman *** 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_at_cygwin.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
isn't or hasn't 32 bit support going or gone away?
I thought I remember an announcement about 32-bit support going away in cygwin and that cygwin would only be built for 64-bit? Am I imagining this or was this reversed? Thanks... -- 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
No gawk-doc package, gawk source autoconf fails
Looked for gawk doc in /usr/share/doc/gawk*/ - no HTML, PDF etc. Checked for gawk doc as a package - no gawk-doc or anything like it. Downloaded gawk package source and tried to configure enough to build doc. Seems to be problem with autoconf autopoint gettext package version - something run by autoreconf seems to be detecting gettext 0.19.8-1 as 0.19.8.1 instead of 0.19.8 which causes autopoint to fail: Preparing gawk-4.1.4-1.x86_64 Unpacking source gawk-4.1.4.tar.xz Preparing working source directory Compiling gawk-4.1.4-1.x86_64 autoreconf-2.69: Entering directory `.' autoreconf-2.69: running: /usr/bin/autopoint -V 0.19.8.1 --force autopoint: warning: Version mismatch: specified -V 0.19.8.1 but the package uses gettext version 0.19.7. Forcibly upgrading to 0.19.8.1 autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac file requires the infrastructure from gettext-0.19.8.1 but this version is older. Please upgrade to gettext-0.19.8.1 or newer. autopoint: *** Stop. autoreconf-2.69: /usr/bin/autopoint failed with exit status: 1 *** ERROR: autoreconf failed Manual configure && make pdf works okay. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: No gawk-doc package, gawk source autoconf fails
On 2016-11-09 18:02, Brian Inglis wrote: Looked for gawk doc in /usr/share/doc/gawk*/ - no HTML, PDF etc. Checked for gawk doc as a package - no gawk-doc or anything like it. Downloaded gawk package source and tried to configure enough to build doc. Seems to be problem with autoconf autopoint gettext package version - something run by autoreconf seems to be detecting gettext 0.19.8-1 as 0.19.8.1 instead of 0.19.8 which causes autopoint to fail: This is already fixed in cygport git master. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
XWin server, idle, using lots of CPU time
I received a new laptop at work (Windows 7 Pro) and installed Cygwin from scratch, including the Xorg server and xdg. Unlike my old laptop, XWIN seems to be using about 10% CPU *all the time* (measured with Task Manager), even when there are no clients connected to it. My ~/ home directory is the same, so the X server is being set up the same way as before, as far as I can tell. The processor is an I7-6600U with two cores, two threads/core. 10% seems rather high, given that 25% would be one fully-utilitized thread. I even updated the Intel video driver to the latest Dell version, dated November 1, 2016. No change in behavior. I've attached cygcheck.out and my X server log, but can anyone advise how to track down the source of the problem? There does seem to be a large number of winClipboardFlushXEvents failures in the Xwin log file, but those are also in the log file on the old laptop. This is how I'm starting the X server: C:\Cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin" I am starting the X server with this line in .xserverrc exec /usr/bin/XWin -notrayicon "$@" Thanks - Jim -- Jim Reisert AD1C, , http://www.ad1c.us cygcheck.out Description: Binary data XWin.0.log Description: Binary data -- 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: WinXP is dead [WAS: 2.6.x: broken compatibility with Wine]
Hi cyg Simple, On 11/9/2016 7:59 AM, Andrey Gursky wrote: >> >> P.S. Was it not too early to remove WinXP support? Though it is >> officially not supported anymore, there are still PCs running WinXP >> (and Wine). Also there are still systems, I've heard, using some >> embedded Windows, that shares the same code with WinXP, thus making it >> not yet truly obsolete. Additionally a lot of work has been done by >> Cygwin contributors to support this OS and I believe the most of bugs >> have been workarounded, while due to stopped development it is not >> likely one has to spend time solving new problems. So was it really >> worth to drop the hardly crafted code? Are there already some >> worthwhile advantages? Why wasn't it possible to switch Cygwin WinXP >> support to just "not officially supported"? (kindly asking) > > This has been answered. The problem with supporting XP into infinitude > is that every application would need to agree to do the same. > Improvements to the OS API would not be able to be used so there are > trade-offs for the continued support of an OS that is no longer > supported. The code becomes unwieldy to maintain because a change needs > to be tested on other systems. Security maintenance becomes impossible > because the OS vendor no longer supports the older OS. There is the > cygwin time machine, USE IT if you need old software for old OS. Thanks for your reply (however I haven't received it, because you likely didn't click on "reply all"?). Do you refer to the recent message [1]? Regarding cygwin time machine. I can't use it, since cygwin is compiled for MSYS2. And then it is being run under Wine on GNU/Linux. While WinXP is still not dead, Wine is definitively not an old OS. It's just an active project doing WinAPI implementation from scratch according to documentation. Thus I hope Cygwin developers could talk directly to Wine ones to find the minimum needed changes in both projects. Regards, Andrey [1] Re: New Cygwin "setup" program useless on my Win-XP box. Not very nice at all. https://cygwin.com/ml/cygwin/2016-11/msg00060.html -- 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: New Cygwin "setup" program useless on my Win-XP box. Not very nice at all.
>> Cygwin installation on XP >> 1. Use the following version of setup*.exe: >> 32-bit: ftp://www.fruitbat.org/pub/cygwin/setup/snapshots/setup-x86-2.874.exe >> 2. Run setup*.exe with the -X option, using the following mirror: >> 32-bit: ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223 Thank you for this really helpful distillation. I followed the instructions exactly, with the minor and probably unnecessary preparation of using regedit to remove from the registry all mentions of Cygnus / Cygwin (because I have occasionally found that previous installations - or, rather, usages - of Cygwin interfere with the groundwork for new usages). And everything worked - in principle, but not in practice. After initiating setup I selected "Download without Installing", clicked on the roundel to select "All" instead of "Default" in order to achieve a Full download rather than the Base download, and away we went. BUT (a) the download appeared to be very slow, which I attributed to properties of fruitbat.org or even the download site ftp://.../104223 which I guess is in some sense virtual (?); however (b) when I checked things this morning having set the thing going last night, I found that in 6 hours only 2048-cli/, 2048-qt/ and the beginnings of 4ti2/ had been downloaded, i.e. the merest starting fragment of what was anticipated. So: the logic seems just fine, the implementation flawed in some way, or on this occasion. Q1 Any ideas of what might be de-railing this simple operation? Q2 [... virtual(?);] Could one instead use wget on ftp://www.fruitbat.org/pub/cygwin/circa/2016/08/30/104223? This would be easy to initiate, it would avoid the layer of complication induced by setup (and anyway I only want a download, not a setup) and finally - really usefully, since the intention is to build a local mirror and then maybe do something useful with it - it would pull down the *src files, which are a pain in setup, requiring individual ticking of many many checkboxes. But: I tried wget, and just came to a halt with no files found. Thank you. Fergus -- 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