Fwd: Cygwin 3.4.9 - how to install ssh-keygen
I can't see a command like cygcheck -p ssh-keygen as noticeably more cumbersome than comparable commands of other distributions Lee via Cygwin schrieb am Mo., 20. Nov. 2023, 23:42: > On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote: > > > > Dear all, > > > > I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10. > > After installing defaults plus openssh 9.5p 1-1, I open the > Cygwin64-Terminal as Administrator and > > run ssh-host-config. > > * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config > > * Answered "no" to use StrictMode > > * and "yes" to install sshd as a service > > * I just press for the question for "Value of CYGWIN for the > daemon". > > cygrunsrv -S cygsshd will not start the sshd. The logfile say "no > hostkeys available". > > > > Unfortunately I can't find ssh-keygen in the installable packages. > > Howto install ssh-keygen or how to create hostkeys? > > The easy way to see if it's already installed > $ which ssh-keygen > /usr/bin/ssh-keygen > > If no, Cygwin is a bit of a pain when looking for a program that's > included in another package. > > There's probably a better way, but I use the cygwin package search - eg: > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=ssh-keygen > and then take a guess as the most likely candidate in the results list > and click on that link to see if it's included in that package - eg > > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-9.5p1-1=ssh-keygen > > > Regards > Lee > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.9 - how to install ssh-keygen
Am 20.11.2023 um 17:54 schrieb Matthias--- via Cygwin: Unfortunately I can't find ssh-keygen in the installable packages. That's quite strange, given ssh-keygen is clearly right there in that openssh package: $ cygcheck -f /usr/bin/ssh-keygen.exe openssh-9.5p1-1 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Compile win64 filesys kernel module only with Cygwin tools?
Am 09.08.2023 um 21:17 schrieb Wendy Lin via Cygwin: How can I compile https://github.com/microsoft/Windows-driver-samples/tree/main/filesys/cdfs with Cygwin gcc? You should not be trying to do that. That's deeply system-specific Windows code. It has nothing to with POSIX, Cygwin or anything like that. For that you need a native Windows toolchain, and quite possibly some extra SDK packages from Microsoft to enable building them. MinGW64 (wether stand-alone, or the MSYS(2) hosted one, or the one hosted in Cygwin) might be able to do it. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Use Real LPT port with Cygwin?
Am 18.06.2023 um 21:35 schrieb tlake--- via Cygwin: I can use an emulated LPT port to a shared network printer from Cygwin but I'd like to print to a local LPT port also. The local printer has no IP address. Is it possible to print to a physical LPT port?> If I do this: ls > LPT1: a file called LPT1: is created on the hard drive rather than sending the data to the printer on LPT1: The fact that works at all is a remarkably ancient quirk that made it into MS-DOS by way of it trying to emulate even older quirks from CP/M. We're talking 1970s computing, there. Because the dogma of backwards compatibility is so strong in Seattle, this quirk is still available in Windows to this very day. But as it's a massive DOS-ism that really does not fit into he POSIX world at all, it's not entirely surprising that it doesn't reproduce in a Cygwin shall, just like that --- Linux doesn't do that, either. What you do get instead is a Unix-style /dev tree of device pseudo-files. I might be cool if that gave you a /dev/lpt1 on Cygwin, but alas, I don't think it does. What you do get is a /proc/sys/DosDevices/Global tree. A printer, if existing as a Windows device "LPT1", should show up there as a character device. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [FEEDBACK] Issue with fd_set, FD_ZERO, FD_SET, FD_SETSIZE : Cygwin
Am 07.02.2023 um 07:59 schrieb Yeo Kai Wei via Cygwin: I think I found the issue, I believe it's due to MinGW's build of gcc (I could be wrong). I downloaded "gcc -core" and it worked. You keep talking of "downloading" and "unpacking" things. That indicates a continuing misunderstanding of how Cygwin is supposed to be installed and configured on your machine, and has been the cause of rather a lot of the confusion you've been going through. You should never be doing any of that yourself. You simply (re-)run Cygwin setup and select which packages to install. As such, the process is really a case of "installing" things. Downloading, unpacking and all that is handled by the setup program and its underlying database of packages and their relationships. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GCC doesn't find relative includes when passed paths using backward-slashes
Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin: The build system, finding it is running on Windows, will pass paths with backward slashes to the compiler. And that's wrong. Cygwin is not, for practical intents and purposes, Windows. It just runs on top of it. Yes, backslashed path names do work in some cases on Cygwin (note that in the case at hand, you did have to "" around the name for that to work). But at some point that idea has to be given up to achieve the primary goal of emulating a Unix-like environment. The correct solution thus becomes "Don't do that, then." Fix the build system detection to recognize Cygwin as a type of Unix, and things will almost certainly just work. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Perl has slowed in recent months
Am 18.05.2022 um 03:53 schrieb David Christensen: > I am working on a Perl module that runs on various Unix-like platforms. > When I 'make test' on similar computers: > > FreeBSD 12.3-RELEASE 28 wallclock secs > Debian GNU/Linux 11.3 31 wallclock secs > macOS 11.6.2 36 wallclock secs > Windows 7 / Cygwin 3.3.5-1509 wallclock secs Given the complete lack of information about what that Perl module of yours might be doing, that's hard to have a meaningful discussion about. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: alternatives package dose not install /sbin executables
Am 29.04.2022 um 18:40 schrieb David Rogers via Cygwin: I successfully installed: alternatives1.3.30c-10 OK According to the alternatives package file list I should have the following executables installed: alternatives.exe and update-alternatives.exe, Yes. But I checked my /sbin directory not in that directory. If you examine the package listing once more, you'll find they're actually supposed to be in /usr/sbin. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [:xdigit:] does not work with std::wstring in a Cygwin environment
Am 15.02.2022 um 02:36 schrieb Hans-Bernhard Bröker: Am 13.02.2022 um 19:25 schrieb Achim Gratz: There is no OS specific configuration for Cygwin explicitly, instead there is one for newlib that actually gets used. This piqued my curiosity, so I had a look at how libstdc++ is built. I found that at least for one crucial source file, called ctype_members.cc, cygwin builds do _not_ use the newlib edition, but rather the "generic" one. And that may very well be the problem here. [...] I've taken the liberty of filing this upstream as a GCC/libstdc++ issue. The extremely condensed version of the issue is that libstdc++ builds by selecting config/os/newlib, but it does not pick --enable-clocale=newlib. Enabling the more global --with-newlib flag would do the latter for us, but it might have other, less desirable effects on top of that. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [:xdigit:] does not work with std::wstring in a Cygwin environment
Am 13.02.2022 um 19:25 schrieb Achim Gratz: Gans, Markus writes: This seems to be an internal Cygwin error: https://www.reddit.com/r/cpp_questions/comments/sp52gq/xdigit_does_not_work_with_stdwstring_in_a_cygwin/ […] Question: Why does Cygwin not detect the letters a, b, c, d, e, and f as hexadecimal digits in a wide string? [...] There is no OS specific configuration for Cygwin explicitly, instead there is one for newlib that actually gets used. This piqued my curiosity, so I had a look at how libstdc++ is built. I found that at least for one crucial source file, called ctype_members.cc, cygwin builds do _not_ use the newlib edition, but rather the "generic" one. And that may very well be the problem here. The superficial cause of the problem is that member function _M_initialize_ctype() in libstdc++-v3/config/locale/generic/ctype_member.cc fills most of its array _M_wmask[] with zeroes instead of meaningful character class identifiers. The slightly deeper reason is that the companion array _M_bit[] is also suspiciously full of zeroes. But the real problem, IMHO, is that the type ctype::mask is just a plain char. That overflows the looped shift used to fill _M_bit[], which in turn leads to nonsense in _M_wmask[]. I didn't manage to find where this ctype::mask is defined, but the way it's used here cannot work if it's defined as plain char. The newlib edition of ctype_members.cc loops over just 8 bits instead of 16, which would allow this to work. So we either have to pick up a different type definition of ctype::mask, or a different edition of ctype_members.cc --- I guess it should be the newlib one. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: w32api.h
Am 14.12.2021 um 18:45 schrieb robhic...@gmx.com: Hi Cygwin, I'm compiling a non Cygwin code using ./config, make, make install. How exactly are you using "./config"? Is it a normal GNU autoconf ./configure script? If so, you should probably have made that point to the mingw cross-compilers distributed with cygwin, e.g. ./configure --host=i686-w64-mingw32 Other configuration script generators (hopefully) have similar wayss of pointing them at a compiler target other than the native one. For a non-Cygwin project expecting Windows API headers, a MingW cross compilation like the above is a whole lot more likely to just work than a mash-up Cygwin-with-Windows-headers-on-top one. The make output says /include/w32api file or directory not found. Make output is most likely just a symptom here. The problem happened during configuration. It probably tried to locate those files in $(some_prefix)/include/w32api, but didn't find any prefix that applied. So now $(some_prefix) evaluates to an empty string. I also notice that w32api.h defines every version of windows but stops at windows8. [...] Is it permissible to add #define windows10 0X0603 Well, there's no law forbidding it ;-) But it's fragile (may be overwritten by any update of the package it came from), and would be somewhat beside the point. Those definitions, like it says in the comment right above them, are just a gimmick for the user to make selecting a target version slightly easier. You can just as easily set your WINVER to 0x0603 directly, instead of relying on your locally patched version of a standard header file, where that local change will probably be updated away the very week you completely forget about that tweak you made, many moons ago. And it wouldn't work for anyone else you passed your sources to, either, because they would be lacking that local modification. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Setting up toolchains
Am 27.09.2021 um 13:27 schrieb Anthony Webber: Anyway, I am trying to set up my gcc toolchains in Cygwin, by which I mean that I'm trying to set up the environment so that the right programs are called at the right time by build systems like cmake and waf, or if I want to build in a more manual fashion. Particularly, I want to be able to switch between toolchains easily. That's hardly ever a question of "setting up" the toolchains. It's rather a question of a) which build system those programs you're trying to build uses, and b) how you initialize/use said build systems. GNU autoconf and cmake have relatively mature mechanisms for doing this. For autoconf you just pass --host=... to configure, and that takes care of everything (assuming the package is capable of cross-building in the first place). For cmake you can preload a cmake script like this: cmake -C some/where/preload_mingw.cmake ../../path/to/source where preload_mingw.cmake might look like this: set(CMAKE_CXX_COMPILER "/usr/bin/x86_64-w64-mingw32-g++" CACHE FILEPATH "CXX compiler") set(CMAKE_C_COMPILER "/usr/bin/x86_64-w64-mingw32-gcc" CACHE FILEPATH "C compiler") set(CMAKE_CXX_FLAGS "-D_WIN32_WINNT=0x0601" CACHE STRING "") set(CMAKE_C_FLAGS "-D_WIN32_WINNT=0x0601" CACHE STRING "") set(WIN32 "1" CACHE STRING "") The benefit of doing it this way is that the preload script can stay the same for quite a lot of packages, and the system default compiler does not even enter the picture, so there will be no misled tests. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.3.0-0.1.9814cfd8f693 (TEST)
Am 19.09.2021 um 00:32 schrieb Ken Brown via Cygwin: Finally, I'd like to mention that it's extremely common for autotools-based packages to have an autogen script like Cygwin's (sometimes called bootstrap or bootstrap.sh). There's nothing surprising about this. It's unsurprising to have that state of things in git checkouts. It _is_ very surprising for tarballs, though. Those are generally expected to be buildable without having to run autoconf, automake, gettext, etc. I'm pretty sure the GNU coding standards have required it since day 1. Automake generates tons of makefile real estate just for this. Generally speaking, removing the generated files (configure, aclocal.m4, Makefile.in, etc.) from git, while laudable, comes at the cost of three extra pieces of effort: 1) Unless a simple "autoreconf -is" is sufficient to do the job, a script like autogen.sh has to be prepared and put into the git 2) To the greatest extent feasible, maintainer rules have to be made to actually work to auto-update those generated files without the hassle of having to re-run autogen.sh 3) Preparing a release tarball is no longer quite as simple as just zipping up an other wise unchanged, fresh checkout (without the .git). That checkout will differ from a proper tarball in both directions: there will be files that should be in the tarball, but not in the checked-out copy, and there will be files in the check-out that should not got into the tarball. autogen.sh itself, and the special README telling people about it, are among the latter. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: updatedb broken as of findutils 4.8.0-1 due to bigram.exe no longer being provided
Am 28.08.2021 um 18:23 schrieb Dan Harkless: Looks like it's because in findutils 4.8.0-1, the bigram.exe program is no longer provided, but the /usr/bin/updatedb script (still) depends on it being there: [...] + for binary in $find $frcode $bigram $code + checkbinary /usr/libexec/frcode The version of updatedb in the 4.8.0-1 package does not actually contain those lines. Mention of both $bigram and $code has been removed from the loop construct (and from everywhere else in the script). That's because the old format of find databases, which is the only one actually using bigram and code, was removed from updatedb as of findutils version 4.7, so there really cannot be a need for the bigram tool any more. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1
Am 13.05.2021 um 10:57 schrieb Thomas Wolff: The crash vanishes after removing a few lines from a conditional (if block) where the condition is false. A conditions that's always false, or one that's false during the execution of a particular test case? This smells like wrong calculation of a relative jump (Intel "short jump") by the optimizer. If it were that simple, the problematic change should stand out like the proverbial sore thumb when comparing assembly listings of the two cases. Does it? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Building the python swig tutorial
Am 27.03.2021 um 13:58 schrieb Brad Bell: It appeard that I need to add an non-standard location to a path so that the linker can find these files ? Read those error messages again. It's failing to find things _in_ any of those files, which means it did in fact find all files it was looking for just fine. So no, this is almost certainly no issue with locations of files. It's an issue of not telling the linker that it's supposed to be looking for certain libraries in the first place. But it's virtually impossible to diagnose this sensibly, as you opted not to show any of the actual command(s) you used. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 24.03.2021 um 21:58 schrieb Ken Brown: On 3/24/2021 2:55 PM, Hans-Bernhard Bröker wrote: Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches: > On Mar 22 22:54, Hans-Bernhard Bröker wrote: >> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: It's what WSL Debian creates when I 'ln -s' inside its own filesystem. Windows' own "dir" command shows it as 22.03.2021 22:34 link_to_a [...] But it cannot do anything else with it. Even fsutil doesn't work on that thing: C:\prg\test>fsutil reparsePoint query \\wsl$\Debian\home\hbbro Fehler: Unzulässige Funktion. Are you running WSL1 or WSL2? To the best of my knowledge it's WSL1. I have WSL1, and the stat command such as the one you tried fails in the same way as yours. Nevertheless, a symlink created under WSL is indeed recognized as such by Cygwin. I verified this as follows: 1. Within WSL, $ ln -s foo mysymlink $ cp -a mysymlink /mnt/c/cygwin64/tmp Here it gets a bit weird. The result of that procedure depends on whether the link target, 'foo', exists in cygwin64/tmp prior to running the above commands. If 'foo' exists, the copy of the symlink becomes a Windows native symlink (reparse point class 0xa00c). If it doesn't the copy turns into a reparse point of class 0xa01d, which 'fsutil reparsepoint query' decodes as "name replacement", Cygwin as a (broken) symlink, and 'dir' lists as . In other words, a WSL symlink. It's quite strange that copying a native WSL1 symlink from inside WSL's own file system out into the Windows side of things does _not_ always yield an identical copy. Some layer sitting between WSL and the Windows file system may modify the copy in flight. The same difference applies if, instead of copying an existing symlink, you just have WSL create one directly in the Windows tree, i.e. cd /mnt/c/cygwin64/tmp rm a b touch a ln -s a la ln -s b lb touch b yields a Windows symlink for 'la', and a WSL symlink for 'lb'.
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches: > On Mar 22 22:54, Hans-Bernhard Bröker wrote: >> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: >>> One of those under-documented reparse point types is the WSL symbolic >>> link, which you will notice are supported in Cygwin, removing quite some >>> sway from your argument... >> >> I notice no such thing right now, running the currently available release >> version 3.1.7: >> >> stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error > > What type of WSL symlink is that? It's what WSL Debian creates when I 'ln -s' inside its own filesystem. Windows' own "dir" command shows it as 22.03.2021 22:34 link_to_a [...] But it cannot do anything else with it. Even fsutil doesn't work on that thing: C:\prg\test>fsutil reparsePoint query \\wsl$\Debian\home\hbbro Fehler: Unzulässige Funktion.
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 22.03.2021 um 16:22 schrieb Johannes Schindelin: On Mon, 15 Mar 2021, Hans-Bernhard Bröker wrote: Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches: That argument might hold more sway if Windows itself didn't quite so completely hide that information from users, too. "So completely"? It at least executes them, and it does offer you to turn them aliases on and off (see https://www.tenforums.com/tutorials/102096-manage-app-execution-aliases-windows-10-a.html) That's a completely different piece of information than what you want Cygwin to show. Granted, the user interface has a lot of room for improvement, but if you are dead set on finding out what, say, that `idle.exe` app execution alias refers to, you can go to `Settings>Apps>Apps & features>App execution aliases` and find out that it is owned by the Python 3.7 package. Knowing which package that thing came from has essentially nothing to do with what its interpretation as a symlink would look like. Apples and Oranges. The `fsutil` program, contrary to your claim, is available without WSL: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil And that very page tells me, in a big "Notice" blurb: You must enable Windows Subsystem for Linux before you can run fsutil. Run the following command as Administrator in PowerShell to enable this optional feature: One of those under-documented reparse point types is the WSL symbolic link, which you will notice are supported in Cygwin, removing quite some sway from your argument... I notice no such thing right now, running the currently available release version 3.1.7: stat: cannot stat '//wsl$/Debian/home/hbbro/link_to_a': Input/output error [other commands that want to show more than just the name behave equivalently] Links made by WSL directly on a Windows filesystem are understood by Cygwin. But that's because WSL uses Windows symlinks in that case. Microsoft could almost certainly just have used a symlink to implement this rather trivial feature. But for some reason they apparently didn't care to explain anywhere, they chose to wildly overcomplicate it, inventing a completly type of reparse point. So for what it's worth, that thing _is_not_a_symlink_. Pretending it is one is bound to cause more problems than it solves. Well, that's funny: you are talking to one Cygwin user who needs to see it. So I feel a bit ignored by you there. All conclusions based on a single example are wrong.
Re: [PATCH 1/2] Treat Windows Store's "app execution aliases" as symbolic links
Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches: Hi Joe, On Sat, 13 Mar 2021, Joe Lowe wrote: I agree on the usefulness to the user of showing appexec target executable as symlink target. But I am uncertain about the effect on code. Maybe. But I am concerned about the effect of not being able to do anything useful with app execution aliases in the first place. That argument might hold more sway if Windows itself didn't quite so completely hide that information from users, too. I found only one Windows native tool that will even show _any_ kind of information about these reparse points: fsutil. That is a) only available as part of the highly optional WSL feature and b) only gives you a hexdump of the actual data, without any meaningful interpretation. For something that Windows itself gives the "no user servicable parts inside" treatment to the extent it does for these reparse points, I rather doubt that Cygwin users really _need_ to see it.
Re: CRITICAL ls MEMORY LEAK
Am 22.02.2021 um 21:30 schrieb Brian Inglis: I've often wondered if the heavy activity is due to Windows' defaults to writing files with F+RX perms which triggers executable virus scans? That could only be the case if Windows actually had an 'x' permission bit. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: thrd_sleep
Am 29.01.2021 um 00:36 schrieb Rafał Jopek via Cygwin: Hi, What package should be installed ? None. This is quite certainly a packaging mistake on a package you already have installed. In short: that file should be in cygwin-devel, but it isn't. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: How to reinstall everything?
Am 17.01.2021 um 19:23 schrieb matthew patton via Cygwin: can we fix setup.exe to read STDIN with '-P', like so? To fix something, it has to be broken first. I don't see that being the case here. echo 'pkg1,pkg2,pkg3' | setup.exe -P - I don't see that in any way easier or more helpful than setup -P pkg1,pkg2,pkg3 which, IIRc, already works. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Can't open display issue from CMD
Am 16.01.2021 um 05:40 schrieb Marco Atzeri via Cygwin: It seems the remote machine is expecting to run a X interface by default. Or could it be that the local machine has ssh X11 forwarding turned on (for this remote machine)? Turning it off explicitly (-x flag) would turn it off, so if that changes the outcome, you know what happened. Running ssh in -v (verbose) may also help with telling what's going on. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: "ls" sorts wrongly if given large number of files
Am 06.01.2021 um 19:17 schrieb Kamran via Cygwin:
Hi all
"ls" (version 8.26) sorts wrongly if given large number of files via
"find" or "xargs"
Actually ls is working just fine here. You just misunderstand how
"find" works in this case.
To see what actually happens, you should run
find -type f -exec echo {} + | wc -l
in that same directory you did your test case in. You'll find it does
_not_ print 1. Now ponder what that means.
For further information, RTFM at:
info "finding files" Actions run multi
about how find builds the command lines it sends to the programs to be
run by "-exec"
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Is it possible to define the root directory in a cross compiled program
Am 05.01.2021 um 22:04 schrieb Andrey Repin: It's a Windows program - it can do whatever you program it to do! On Windows the device is NUL, the root is the drive root C:\, %SystemDrive%\ to be precise. Well, since we're being precise: no. %SystemDrive%\ is the root of the drive the system is on. That's not "the" root any more than c:\, \ or any other such thing. The actual answer would be: no DOS-style path (i.e. neither c:\ nor \) can be usefully called "the" root on a Windows machine. The closest to an actual root on a Windows system would be something like \\?\ or \\.\ -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GAWK Incorrect Data Display
Am 20.12.2020 um 00:34 schrieb Jason McGee via Cygwin: I confirmed there is not a problem with my code by comparing Cygwin against Gawk for Windows. Your presentation of the problem is quite unclear, but the root cause is almost certainly not in the code, but in the data. You're bound to be feeding Windows text files to a Unix tool. You need to reformat the file to Unix format. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: lookup problem in compiler
Am 15.11.2020 um 04:59 schrieb Juan carlos Rebate via Cygwin: Hello, I am trying to compile certain programs in windows 10 and I have a curious problem, I use mingw64-x86_64-w64-mingw, when I add related packages if it is able to locate them but if I install packages that are not related it is not able to locate them, MinGW64 GCC is a cross-compiler. It builds native Windows programs, which are a rather different thing than Cygwin programs. Development packages for the native cygwin compiler generally do not provide anything usable for the cross-compiler. It would be wrong for the MinGW cross-compiler to find them. If it did find them, very little in terms of useful results could possibly come of it. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Reg facing Cygwin Issue while downloading the code.
Am 04.11.2020 um 10:36 schrieb Ponnusamy, Sathiyamoorthy (Extranet) via Cygwin: Hi Team, I am facing Cygwin issue while downloading the code. I don't think you do. Cygwin has very little, if anything, to do with this issue. I need this Cygwin tool urgently for the current project release. Kindly suggest me. You're being less than completely clear. What "this Cygwin tool" is that? UX012677@s2bvdiw10dv0292 /cygdrive/c/api/dev/dev_2015/build_rcdev $ cmake -DRCDEV_ROOT_SOURCE_NAME=rfasl -DRCDEV_ROOT_SOURCE_REPO_ID=RFACPP_INTG -G "Visual Studio 14 2015 Win64" ../rcdev I know of no sane reason to use the Cygwin version of cmake to configure a native VisualStudio build of your project. Surely the Windows native version of cmake would be the better choice in that case. [...] CMake Warning (dev) at C:/api/dev/dev_2015/rcdev/build/external/BUILD/libxml2/build/libxml2_config.cmake:1 (execute_process): Syntax error in cmake code at C:/api/dev/dev_2015/rcdev/build/external/BUILD/libxml2/build/libxml2_config.cmake:2 when parsing string prefix=C:\api\dev\dev_2015\rcdev\build\install This is clearly Windows native syntax in a cmake script. That's either a bug in that package's cmake files, or a consequence of using the wrong tool for the job. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: TMP/TEMP environment variable and /tmp
Am 16.09.2020 um 13:12 schrieb Thomas Wolff: Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin: On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin Does anyone know the rational with this behaviour and what can be done to get hold of the (real) Windows TMP/TEMP environment-variable-values (in a (hopefully) platform independent way) ? so if you are making your custom tree, try to stick on that expectation and have both directories. In general, you are free to set TMP to a directory of your choice, that's the purpose of that variable, no need to sync it with some root. There is a comment in /etc/profile: # TMP and TEMP as defined in the Windows environment # can have unexpected consequences for cygwin apps, but it does not explain what consequences that might be; probably some trouble with ACL/access permissions for temporary files. Nowadays that would be $LOCALAPPDATA/Temp, or if you really insist, the content of /proc/registry/HKEY_CURRENT_USER/Environment/TMP (or TEMP), after similarly expanding environment variable references found in that. The fact that getting Windows' idea of the user's TEMP directory is not immediately platform independent may well have been part of the rationale for not even trying that. A bigger part of the reason may have been what the result of that platform-dependent query would have been, back when the decision had to be made. For several releases you would have ended up with (your locally translated version of!) stupid old "Documents and Settings" as part of the pathname, and possibly some extra blanks and special characters from the user name, on top of that. And I for one really do not trust that a Unix temp directory can safely have white space in its name without breaking lots of tools' behavior in nastily interesting ways. IIRC it took until Windows 8 for Microsoft to finally own up to their error and change it to the profoundly less insane "Users". But by then it was too late, all the damage had been done already. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: update with apt-cyg ?
Am 07.09.2020 um 01:00 schrieb Ulli Horlacher: cygstart /setup-x86_64.exe --quiet-mode That approach is essentially guaranteed to fail you in frustrating ways, for two reasons: 1) (Minor) You do not want to have setup itself, much less its work and data directory, inside the cygwin installation. I.e. that should never be '/' as the path for setup, as seen from any Cygwin shell. 2) (Major) Updating a running cygwin installation from the inside is highly unlikely to work correctly. Most importantly there is almost no chance for it to update the core DLLs, because those will already be in use by the shell you're running this from, so they cannot be changed. I.e. if you're in a situation where using "cygstart" makes any sense, that's a situation setup cannot update the DLLs. In a nutshell, and to paraphrase a certain Mr. Ford, you can have your special non-interactive Cygwin setup script in any language you like, as long as it's effectively a _Windows_ batch file. Updating the branch you're currently sitting on does not work any better than sawing it through. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: undetectable libraries
Am 28.08.2020 um 00:51 schrieb Juan carlos Rebate via Cygwin: good evening, I have a strange problem, I try to compile code that uses gtk3 and sdl2 in addition to curl, Would you mind revealing what code that is? the problem is that when I invoke the gcc compiler it tells me that sdl2-devel and libcurl are not installed, but actually yes are. I'm pretty sure that GCC would never tell you those particular things. It would tell you which files it cannot find, but not which package they're supposed to be from. ./configure --cross-prefix=x86_64-w64-mingw32- --enable-sdl --enable-gtk --enable-curl That configure call looks strange, particularly the --cross-prefix part. The usual way of asking configure to build for a target platform other than the build host would look more like this: ./configure --host=x86_64-w64-mingw32 The actual output from your configure run, and/or the generated config.log file would almost certainly be more helpful than further speculation about the details of cygwin setup usage. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: help compilation qemu
Am 24.05.2020 um 17:30 schrieb Juan carlos Rebate via Cygwin: [Can you _please_ cut down on the TOFU? Thanks ] Hi Caba, I know qemu-system-i386 because the official binary is that \ size.As for the command used I use this:x86_64-w64-mingw32- this way it ^^ Those two marked details form a mismatch. If it's the i386 version you're trying to build, then the tool chain (equivalent to the --target argument in configure) is i686-w64-mingw32. compiles perfectly except for the file sizes, if I add the option - s Add it where? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
Am 20.03.2020 um 00:18 schrieb Brian Inglis: On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote: It seems something is adding 5M or more to the normal size of the programs See attached for summary details by arch, but main points for both are, on x86_64: [...] Could this be due to the ginormous number of targets configured into the build? Asking the tools themselves about the list of targets they support, compared to a run-off-the-mill default native build from current git sources, yields: hbbro@NB5 ~/src/gnu/binutils/bld/gcc/binutils $ objdump -i | wc 8172 30919 441168 hbbro@NB5 ~/src/gnu/binutils/bld/gcc/binutils $ ./objdump -i | wc 117 3252831 That size difference evidently due to the 260+ supported output target types in /usr/bin/objdump.exe, compared to 22 in my own build. To put it another way the individual object files in libbfd.a are of quite similar size; there just a whole lot more of them, and that explains the difference. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH 2/2] Do not bother passing optional argument to WriteConsoleA.
Passing a pointer to a local variable to WriteConsoleA is
not actually needed if we're not going to do anything with
what WriteConsoleA would put in there.
For the wpbuf class the pointer argument was made optional,
so it can be just left out; other call places now pass a
NULL pointer instead. The local variables `wn' and `n'
are no unused, so they go away.
---
winsup/cygwin/fhandler_console.cc | 51 ++-
1 file changed, 23 insertions(+), 28 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 9d7a9e9ea..1c376291f 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -2015,7 +2015,6 @@ fhandler_console::char_command (char c)
if (wincap.has_con_24bit_colors () && !con_is_legacy)
{
/* For xterm compatible mode */
- DWORD wn;
switch (c)
{
#if 0 /* These sequences, which are supported by real xterm, are
@@ -2044,17 +2043,17 @@ fhandler_console::char_command (char c)
wpbuf.put (c);
if (wincap.has_con_esc_rep ())
/* Just send the sequence */
- wpbuf.send (get_output_handle (), );
+ wpbuf.send (get_output_handle ());
else if (last_char && last_char != '\n')
for (int i = 0; i < con.args[0]; i++)
- WriteConsoleA (get_output_handle (), _char, 1, , 0);
+ WriteConsoleA (get_output_handle (), _char, 1, 0, 0);
break;
case 'r': /* DECSTBM */
con.scroll_region.Top = con.args[0] ? con.args[0] - 1 : 0;
con.scroll_region.Bottom = con.args[1] ? con.args[1] - 1 : -1;
wpbuf.put (c);
/* Just send the sequence */
- wpbuf.send (get_output_handle (), );
+ wpbuf.send (get_output_handle ());
break;
case 'L': /* IL */
if (wincap.has_con_broken_il_dl ())
@@ -2072,27 +2071,27 @@ fhandler_console::char_command (char c)
srBottom - (n-1) - con.b.srWindow.Top + 1,
y + 1 - con.b.srWindow.Top, x + 1);
WriteConsoleA (get_output_handle (),
-buf, strlen (buf), , 0);
+buf, strlen (buf), 0, 0);
}
__small_sprintf (buf, "\033[%d;%dr",
y + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
- WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
+ WriteConsoleA (get_output_handle (), buf, strlen (buf), 0, 0);
wpbuf.put ('T');
- wpbuf.send (get_output_handle (), );
+ wpbuf.send (get_output_handle ());
__small_sprintf (buf, "\033[%d;%dr",
srTop + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
- WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
+ WriteConsoleA (get_output_handle (), buf, strlen (buf), 0, 0);
__small_sprintf (buf, "\033[%d;%dH",
y + 1 - con.b.srWindow.Top, x + 1);
- WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
+ WriteConsoleA (get_output_handle (), buf, strlen (buf), 0, 0);
}
else
{
wpbuf.put (c);
/* Just send the sequence */
- wpbuf.send (get_output_handle (), );
+ wpbuf.send (get_output_handle ());
}
break;
case 'M': /* DL */
@@ -2105,22 +2104,22 @@ fhandler_console::char_command (char c)
__small_sprintf (buf, "\033[%d;%dr",
y + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
- WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
+ WriteConsoleA (get_output_handle (), buf, strlen (buf), 0, 0);
wpbuf.put ('S');
- wpbuf.send (get_output_handle (), );
+ wpbuf.send (get_output_handle ());
__small_sprintf (buf, "\033[%d;%dr",
srTop + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
- WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
+ WriteConsoleA (get_output_handle (), buf, strlen (buf), 0, 0);
__small_sprintf (buf, "\033[%d;%dH",
y + 1 - con.b.srWindow.Top, x + 1);
- WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
+ WriteConsoleA (get_output_handle (), buf, strlen (buf), 0, 0);
}
else
{
wpbuf.put (c);
/* Just send the sequence */
- wpbuf.send (get_output_handle (), );
+ wpbuf.send (get_output_handle ());
[PATCH 1/2] Collect handling of wpixput and wpbuf into a helper class.
Replace direct access to a pair of co-dependent variables
by calls to methods of a class that encapsulates their relation.
Also replace C #define by C++ class constant.
---
winsup/cygwin/fhandler_console.cc | 141 --
1 file changed, 76 insertions(+), 65 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index c5f269168..9d7a9e9ea 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -59,17 +59,28 @@ static struct fhandler_base::rabuf_t con_ra;
/* Write pending buffer for ESC sequence handling
in xterm compatible mode */
-#define WPBUF_LEN 256
-static unsigned char wpbuf[WPBUF_LEN];
-static int wpixput;
static unsigned char last_char;
-static inline void
-wpbuf_put (unsigned char x)
+/* simple helper class to accumulate output in a buffer
+ and send that to the console on request: */
+static class write_pending_bufferOA
{
- if (wpixput < WPBUF_LEN)
-wpbuf[wpixput++] = x;
-}
+private:
+ static const size_t WPBUF_LEN = 256u;
+ unsigned char buf[WPBUF_LEN];
+ size_t ixput;
+public:
+ inline void put (unsigned char x)
+ {
+if (ixput < WPBUF_LEN)
+ buf[ixput++] = x;
+ }
+ inline void empty () { ixput = 0u; }
+ inline void send (HANDLE , DWORD *wn = NULL)
+ {
+WriteConsoleA (handle, buf, ixput, wn, 0);
+ }
+} wpbuf;
static void
beep ()
@@ -2030,10 +2041,10 @@ fhandler_console::char_command (char c)
break;
#endif
case 'b': /* REP */
- wpbuf_put (c);
+ wpbuf.put (c);
if (wincap.has_con_esc_rep ())
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.send (get_output_handle (), );
else if (last_char && last_char != '\n')
for (int i = 0; i < con.args[0]; i++)
WriteConsoleA (get_output_handle (), _char, 1, , 0);
@@ -2041,9 +2052,9 @@ fhandler_console::char_command (char c)
case 'r': /* DECSTBM */
con.scroll_region.Top = con.args[0] ? con.args[0] - 1 : 0;
con.scroll_region.Bottom = con.args[1] ? con.args[1] - 1 : -1;
- wpbuf_put (c);
+ wpbuf.put (c);
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.send (get_output_handle (), );
break;
case 'L': /* IL */
if (wincap.has_con_broken_il_dl ())
@@ -2067,8 +2078,8 @@ fhandler_console::char_command (char c)
y + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
- wpbuf_put ('T');
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.put ('T');
+ wpbuf.send (get_output_handle (), );
__small_sprintf (buf, "\033[%d;%dr",
srTop + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
@@ -2079,9 +2090,9 @@ fhandler_console::char_command (char c)
}
else
{
- wpbuf_put (c);
+ wpbuf.put (c);
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.send (get_output_handle (), );
}
break;
case 'M': /* DL */
@@ -2095,8 +2106,8 @@ fhandler_console::char_command (char c)
y + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
- wpbuf_put ('S');
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.put ('S');
+ wpbuf.send (get_output_handle (), );
__small_sprintf (buf, "\033[%d;%dr",
srTop + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
@@ -2107,13 +2118,13 @@ fhandler_console::char_command (char c)
}
else
{
- wpbuf_put (c);
+ wpbuf.put (c);
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.send (get_output_handle (), );
}
break;
case 'J': /* ED */
- wpbuf_put (c);
+ wpbuf.put (c);
if (con.args[0] == 3 && wincap.has_con_broken_csi3j ())
{ /* Workaround for broken CSI3J in Win10 1809 */
CONSOLE_SCREEN_BUFFER_INFO sbi;
@@ -2131,7 +2142,7 @@ fhandler_console::char_command (char c)
}
else
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.send (get_output_handle (), );
[PATCH 0/2] wpbuf class-ification
Second shot at wpbuf class-ification. Also no longer request data from WriteConsoleA that is not used for anything. Hans-Bernhard Broeker (2): Collect handling of wpixput and wpbuf into a helper class. Do not bother passing optional argument to WriteConsoleA. winsup/cygwin/fhandler_console.cc | 164 -- 1 file changed, 85 insertions(+), 79 deletions(-) -- 2.21.0
[PATCH 0/2] wpbuf class-ification
Second shot at wpbuf class-ification. Also no longer request data from WriteConsoleA that is not used for anything. Hans-Bernhard Broeker (2): Collect handling of wpixput and wpbuf into a helper class. Do not bother passing optional argument to WriteConsoleA. winsup/cygwin/fhandler_console.cc | 164 -- 1 file changed, 85 insertions(+), 79 deletions(-) -- 2.21.0
Re: Has rename syntax changed?
Am 04.03.2020 um 04:52 schrieb L A Walsh: On 2020/03/03 15:45, Hans-Bernhard Bröker wrote: Am 04.03.2020 um 00:25 schrieb L A Walsh: On 2020/02/28 04:38, Fergus Daly wrote: I am almost certain that the command $ rename "anything" "AnyThing" *.ext would alter the string from lc to uc as shown, anywhere it occurred in any filename in *.ext in the current directory. isn't that they same as "mv anything.xxx Anything.xxx" ? No. For three reasons: *) it's .ext, not .xxx :-) *) it will find and replace 'anything' _anywhere_in_ the filename, not just in the basename. I'm confused about your terminology. The terminology is fine, but the statement isn't quite. That had better have read: >> it will find and replace 'anything' _anywhere_in_ the filename, not >> just if that's the entire basename. You said all of the filenames must match '*.ext'. No, I didn't. I said that rename will work on all files in the cwd matching *.ext. Files in the cwd not matching *.ext will be left alone. -- 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: Has rename syntax changed?
Am 04.03.2020 um 00:25 schrieb L A Walsh: On 2020/02/28 04:38, Fergus Daly wrote: I am almost certain that the command $ rename "anything" "AnyThing" *.ext would alter the string from lc to uc as shown, anywhere it occurred in any filename in *.ext in the current directory. isn't that they same as "mv anything.xxx Anything.xxx" ? No. For three reasons: *) it's .ext, not .xxx :-) *) it will find and replace 'anything' _anywhere_in_ the filename, not just in the basename. *) it will do so on _all_ files in the cwd matching '*.ext', not just a single one --- that's its entire purpose. -- 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: [PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.
Am 03.03.2020 um 01:35 schrieb Takashi Yano:
The second argument DWORD *wn of sendOut() is not used
outside sendOut(), so it can be covered up like:
inline void sendOut (HANDLE )
{
DWORD wn;
WriteConsoleA (handle, buf, ixput, , 0);
}
I doubt that will improve much, if anything. There are still direct
calls to WriteConsoleA() left, working on other buffers, and those still
use the DWORD wn defined near the top of
fhandler_console::char_command(). So that the existing varialbe would
have to be kept anyway. That means the variables local to each
invocation (!) of wpbuf.sendOut would just clutter the stack for no gain.
OTOH the MS documentation calls this DWORD* an "optional output"
argument. If I'm reading that right, it means it should be fine to just
pass NULL to indicate that we don't need it:
inline void sendOut (HANDLE )
{
WriteConsoleA (handle, buf, ixput, 0, 0);
}
The same would apply to all the other calls of WriteConsoleA, it seems.
[PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.
Replace direct access to a pair of co-dependent variables
by calls to methods of a class that encapsulates their relation.
Also replace C #define by C++ class constant.
---
winsup/cygwin/fhandler_console.cc | 135 --
1 file changed, 70 insertions(+), 65 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index c5f269168..af2fb11a4 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -59,17 +59,22 @@ static struct fhandler_base::rabuf_t con_ra;
/* Write pending buffer for ESC sequence handling
in xterm compatible mode */
-#define WPBUF_LEN 256
-static unsigned char wpbuf[WPBUF_LEN];
-static int wpixput;
static unsigned char last_char;
-static inline void
-wpbuf_put (unsigned char x)
+// simple helper class to accumulate output in a buffer
+// and send that to the console on request:
+static class WritePendingBuf
{
- if (wpixput < WPBUF_LEN)
-wpbuf[wpixput++] = x;
-}
+private:
+ static const size_t WPBUF_LEN = 256u;
+ unsigned char buf[WPBUF_LEN];
+ size_t ixput;
+
+public:
+ inline void put(unsigned char x) { if (ixput < WPBUF_LEN) {
buf[ixput++] = x; } };
+ inline void empty() { ixput = 0u; };
+ inline void sendOut(HANDLE , DWORD *wn) { WriteConsoleA
(handle, buf, ixput, wn, 0); };
+} wpbuf;
static void
beep ()
@@ -2030,10 +2035,10 @@ fhandler_console::char_command (char c)
break;
#endif
case 'b': /* REP */
- wpbuf_put (c);
+ wpbuf.put (c);
if (wincap.has_con_esc_rep ())
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
else if (last_char && last_char != '\n')
for (int i = 0; i < con.args[0]; i++)
WriteConsoleA (get_output_handle (), _char, 1, , 0);
@@ -2041,9 +2046,9 @@ fhandler_console::char_command (char c)
case 'r': /* DECSTBM */
con.scroll_region.Top = con.args[0] ? con.args[0] - 1 : 0;
con.scroll_region.Bottom = con.args[1] ? con.args[1] - 1 : -1;
- wpbuf_put (c);
+ wpbuf.put (c);
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
break;
case 'L': /* IL */
if (wincap.has_con_broken_il_dl ())
@@ -2067,8 +2072,8 @@ fhandler_console::char_command (char c)
y + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
- wpbuf_put ('T');
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.put ('T');
+ wpbuf.sendOut( get_output_handle (), );
__small_sprintf (buf, "\033[%d;%dr",
srTop + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
@@ -2079,9 +2084,9 @@ fhandler_console::char_command (char c)
}
else
{
- wpbuf_put (c);
+ wpbuf.put (c);
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
}
break;
case 'M': /* DL */
@@ -2095,8 +2100,8 @@ fhandler_console::char_command (char c)
y + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
WriteConsoleA (get_output_handle (), buf, strlen (buf), , 0);
- wpbuf_put ('S');
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.put ('S');
+ wpbuf.sendOut( get_output_handle (), );
__small_sprintf (buf, "\033[%d;%dr",
srTop + 1 - con.b.srWindow.Top,
srBottom + 1 - con.b.srWindow.Top);
@@ -2107,13 +2112,13 @@ fhandler_console::char_command (char c)
}
else
{
- wpbuf_put (c);
+ wpbuf.put (c);
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
}
break;
case 'J': /* ED */
- wpbuf_put (c);
+ wpbuf.put (c);
if (con.args[0] == 3 && wincap.has_con_broken_csi3j ())
{ /* Workaround for broken CSI3J in Win10 1809 */
CONSOLE_SCREEN_BUFFER_INFO sbi;
@@ -2131,7 +2136,7 @@ fhandler_console::char_command (char c)
}
else
/* Just send the sequence */
- WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
+ wpbuf.sendOut( get_output_handle (), );
break;
[PATCH 0/1] Handle wpbuf in a more C++ style
Replace a relatively C-styled co-dependent pair of variables, a #define, and an inline function by a helper class containing their relation, because that is more in the C++ style. Hans-Bernhard Broeker (1): Collect handling of wpixput and wpbuf into a helper class. winsup/cygwin/fhandler_console.cc | 135 -- 1 file changed, 70 insertions(+), 65 deletions(-) -- 2.21.0
Copyright License waiver
To whom it may concern, I hereby grant anyone the rights to any use code I send here under the standard 2-clause BSD license statement as found, among other places, in winsup/cygwin/CONTRIBUTORS. Hans-Bernhard Bröker
Re: [PATCH v2 1/4] Cygwin: console: Add workaround for broken IL/DL in xterm mode.
Am 01.03.2020 um 07:33 schrieb Takashi Yano: However, from the view point of performance, just inline static function is better. I don't see how that could be the case. Inline methods of a static C++ object should not suffer any perfomance penalty compared to inline functions operating on static variables. Attached code measures the performance of access speed for wpbuf. I compiled it by g++ 7.4.0 with -O2 option. The result is as follows. Total1: 2.315627 second Total2: 1.588511 second Total3: 1.571572 second Strange. The result here (with GCC 9.2) is rather different: $ g++ -O2 -o tt wpbuf-bench.cc && ./tt Total1: 0.753815 second Total2: 0.757444 second Total3: 1.217352 second And on inspection, all three bench*() functions do appear to have exactly the same machine code, too. They may be inlined and mixed into main() somewhat differently, though. That might explain the difference more readily than any actual difference in speed between the three implementations.
Re: [PATCH v2 1/4] Cygwin: console: Add workaround for broken IL/DL in xterm mode.
One more important note: the current implementation has a potential
buffer overrun issue, because it writes first, and only then checks
whether that may have overrun the buffer. And the check itself is off
by one, too:
wpbuf[wpixput++] = x; \
if (wpixput > WPBUF_LEN) \
wpixput--; \
That's why my latest code snippet does it differently:
> if (ixput < WPBUF_LEN)
>{
> buf[ixput++] = x;
>}
Re: [PATCH v2 1/4] Cygwin: console: Add workaround for broken IL/DL in xterm mode.
Am 28.02.2020 um 14:31 schrieb Corinna Vinschen:
[CC Hans]
Thanks. I wasn't subscribed to -patches so far. Will change that.
Hans,
as for making a patch for this issue, may I leave it to you
because you are already working on it?
My patch was meant only as a minimally-invasive stop-gap fix, because
the new GCC refused to compile the code as-is (it triggers a
-Werror...). As such, sorry for hurting Brian's eyes. ;-)
I agree that this really should be an inline function. I barely speak
C++, but even I have glimpsed that multi-statement macros are rightfully
frowned upon in C++ circles.
I believe a more C++-like implementation would have to encapsulate wpbuf
and wpixput into a helper class. This is what my _very_ rusty C++
allowed me to come up with:
// simple helper class to accumulate output in a buffer
// and send that to the console on request:
static class
{
private:
unsigned char buf[WPBUF_LEN];
int ixput;
public:
inline void put(unsigned char x)
{
if (ixput < WPBUF_LEN)
{
buf[ixput++] = x;
}
};
inline void empty() { ixput = 0; };
inline void sendOut(HANDLE , DWORD *wn) {
WriteConsoleA (handle, buf, ixput, wn, 0);
};
} wpbuf;
Using it works like this:
s/wpbuf_put/wpbuf.put/
s/wpixput = 0/wpbuf.empty()/
s/WriteConsoleA ( get_output_handle (), wpbuf, wpixput, \(*n\), 0
/wpbuf.sendOut( get_output_handle (), \1/g
Yes, sendOut() is ugly --- I didn't manage to find out how this class
could access get_output_handle() itself, so I had to let its callers
deal with that.
[PATCH] Properly encapsulate multi-statement macro.
winsup/cygwin/fhandler_console.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 4ab9bcab8..353abd197 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -63,10 +63,11 @@ static struct fhandler_base::rabuf_t con_ra;
static unsigned char wpbuf[WPBUF_LEN];
static int wpixput;
static unsigned char last_char;
-#define wpbuf_put(x) \
+#define wpbuf_put(x) do { \
wpbuf[wpixput++] = x; \
if (wpixput > WPBUF_LEN) \
-wpixput--;
+wpixput--; \
+} while(0)
static void
beep ()
--
2.21.0
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [BUG]: 3.1.4: cmd -> bash -> mintty yields Windows exception
Am 21.02.2020 um 18:22 schrieb David Rothenberger: With cygwin 3.1.4, I get an "exception c005" when I perform the following actions: 1. Use the Windows run box to start a cmd shell 2. From there, run "bash". (I'm sure it is the Cygwin bash.) How did you make sure of that? The output of "where bash" might surprise you. On this box, e.g., I have: C:\Users\hbbro>where bash C:\Windows\System32\bash.exe C:\Users\hbbro>bash hbbro@NB5:/mnt/c/Users/hbbro$ uname -a Linux NB5 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01 16:53:00 PST 2019 x86_64 GNU/Linux But let's assume I did actually start Cygwin bash. 3. From there, run "mintty" C:\Users\hbbro>\cygwin64\bin\bash hbbro@NB5 /cygdrive/c/Users/hbbro $ mintty bash: mintty: command not found So running "mintty" doesn't actually work at all. But let's assume I start Mintty in a way that actually works in this context: hbbro@NB5 /cygdrive/c/Users/hbbro $ /usr/bin/mintty Works just fine. Mintty starts up, all is fine. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Fwd: Re: headache on build repeatibility: octave vs BLODA ?
[Ooops, sent this to Takashi instead of the list, originally.]
Am 29.01.2020 um 14:46 schrieb Takashi Yano:
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
As Octave uses gnulib, it is possible that the changes in MS are causing
a different subset of gnulib to be used than before, may be exposing
a latent bug or race.
Unfortunately my old build tree was polluted by mistake, so I can
not directly compare a good build tree versus a failing one.
I found suspicious difference between the working build and the
not-working build.
The not-working build has fflush.o, fseek.o and fseeko.o in
build/libgnu/.libs
directory, while the working build does not.
Also, cygoctave-7.dll of not-working build exports rpl_fflush,
rpl_fseek and rpl_fseeko, while that of the working build does
not.
That's very interesting, as one of those: rpl_fseeko, is indeed in the
code path to the crash:
=
#0 0x in ?? ()
#1 0x00018019b9c7 in __sflush_r (ptr=ptr@entry=0xd680,
fp=fp@entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:179
#2 0x00018019baeb in _fflush_r (ptr=ptr@entry=0xd680,
fp=fp@entry=0x800080ae8) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fflush.c:278
#3 0x00018019fd67 in _fseeko_r (ptr=0xd680, fp=0x800080ae8,
offset=4, whence=0) at
/usr/src/debug/cygwin-3.1.2-1/newlib/libc/stdio/fseeko.c:314
#4 0x0001801346bb in _sigfe () at sigfe.s:35
#5 0x00042cdc77d9 in c_file_ptr_buf::seekoff (this=0x800223dc0,
offset=, dir=) at
/usr/src/debug/octave-5.1.0-1/libinterp/corefcn/c-file-ptr-stream.cc:118
#6 0x0003d7fd72b3 in cygstdc++-6!_ZNSi5tellgEv () from
/usr/bin/cygstdc++-6.dll
#7 0x00042d0881da in octave::textscan::scan
(this=this@entry=0xb470, isp=..., fmt=..., ntimes=ntimes@entry=2,
options=..., count=@0xb6f8: 0)
=
(Yes, neither fseeko nor rpl_fseeko can bee seen here, but they were
passed as part of executing #5: seekoff.
Here's me stepping into that seekoff() call, in a later gdb session:
=
Thread 1 "doctave-cli" hit Breakpoint 1, c_file_ptr_buf::seekoff
(this=0x800220eb0, offset=0, dir=std::_S_cur) at
/usr/src/debug/octave-5.1.0-1/libinterp/corefcn/c-file-ptr-stream.cc:115
115 {
(gdb) s
116 if (f)
(gdb)
118 octave_fseeko_wrapper (f, offset, seekdir_to_whence (dir));
(gdb)
octave_fseeko_wrapper (fp=0x800080ae8, offset=0, whence=1) at
/usr/src/debug/octave-5.1.0-1/liboctave/wrappers/filepos-wrappers.c:40
40 }
(gdb)
rpl_fseeko (fp=0x800080ae8, offset=0, whence=1) at
/usr/src/debug/octave-5.1.0-1/libgnu/fseeko.c:42
42 {
(gdb)
58if ((fp->_flags & __SL64) == 0)
(gdb)
42 {
(gdb)
58if ((fp->_flags & __SL64) == 0)
(gdb)
70if (fp_->_p == fp_->_bf._base
(gdb)
163 return fseeko (fp, offset, whence);
(gdb)
164 }
(gdb)
163 return fseeko (fp, offset, whence);
(gdb)
/wip/cygport-git/gdb/gdb-8.2.1-1.x86_64/src/gdb-8.2.1/gdb/infrun.c:2723:
internal-error: void resume_1(gdb_signal): Assertion
`pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is a bug, please report it. For instructions, see:
Re: headache on build repeatibility: octave vs BLODA ?
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker: So re-run it in gdb, via libtool (run-octave -g ...). Still crashes, but I didn't manage to get around the SIGSEGV handler in octave. It always caught the SEGV before gdb managed to get there. So my finding, so far, would be that this is related to libtool. Maybe some update to Windows broke the way libtool interacts with not-quite-finished executables... This is getting curiouser. I was intrigued that the stackdump file written was not from 'octave' per se, but rather 'octave-cli'. And indeed some further experiments shows that ../../inst/usr/bin/octave-cli-5.1.0.exe --norc --silent --no-history -p mex ../../src/octave-5.1.0/test/fntests.m ../../src/octave-5.1.0/test fails, while ../../inst/usr/bin/octave-5.1.0.exe --norc --silent --no-history -p mex ../../src/octave-5.1.0/test/fntests.m ../../src/octave-5.1.0/test passes. I don't see how 'run-octave' would end up running octave-cli, though, unless it had been given the option '-cli'. -- 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: headache on build repeatibility: octave vs BLODA ?
Am 25.01.2020 um 17:55 schrieb Marco Atzeri: libinterp/corefcn/file-io.cc-tst ...fatal: caught signal Segmentation fault -- stopping myself... /bin/sh: line 1: 3771 Segmentation fault (core dumped) /bin/sh ../run-octave --norc --silent --no-history -p /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/build/test/mex /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/src/octave-5.1.0/test/fntests.m /cygdrive/d/cyg_pub/devel/octave/prova_311_510/octave-5.1.0-2.x86_64/src/octave-5.1.0/test Can anyone try to rebuild the Octave package and let me know if the segfault during test is present or not in your system ? The problem occurs the same way, here, running Win10 Pro 1909 fully updated (a.k.a. Version 10.0.18363.592), no extra AntiVirus running besides Defender. Be aware that build time is very long (~ 4 hours) and requires a ton of mathematical libraries. The build itself completed in ~30 minutes, here ;-). But then this is a fresh i9, 8-core, 16-thread box. cygport install took ages to complete, though, because objcopy takes spectacularly long to strip those DLLs --- longer than it took to build the whole package! And it does them one at a time. That could profit from some parallelization. So while I waited, I decided to try it with the distributed octave.exe instead. It passes the critical tests without issue. Next step, after cygport inst is done: run the test with the executable in cygport's "inst" directory (to bypass libtool): Success, again! So I tried running the test via libtool, i.e. the run-octave script. And boom it goes. So re-run it in gdb, via libtool (run-octave -g ...). Still crashes, but I didn't manage to get around the SIGSEGV handler in octave. It always caught the SEGV before gdb managed to get there. So my finding, so far, would be that this is related to libtool. Maybe some update to Windows broke the way libtool interacts with not-quite-finished executables... -- 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: grace broken installation
Am 27.01.2020 um 13:58 schrieb Ken Brown:
On 1/26/2020 10:25 PM, Hans-Bernhard Bröker wrote:
Am 25.01.2020 um 15:23 schrieb Rodrigo Medina:
Hi,
Both installations of grace-5.1.24 and grace-5.1.245 are broken.
/usr/bin/xmgrace.exe runs but gives the message:
--> Broken or incomplete installation - read the FAQ!
and then quits.
After reading the FAQ and comparing with a direct build from upstream sources, I
find the reason for that is that the FontDataBase file of the distributed
package is, indeed, wrong.
Apparently the type1 font directory supplied by grace was replaced by a link to
ghostscript's type1 font repository. But the FontDataBase wasn't updated to
match this change. This mismatch causes xmgrace to baulk. This change was made
between revisions 5.1.24 and 5.1.25 of the cygwin package, which neatly explains
why 5.1.24 works, but 5.1.25 does not.
See
https://cygwin.com/ml/cygwin/2018-03/msg00142.html
https://cygwin.com/ml/cygwin/2018-03/msg00156.html
Yes, that's about what I figured. The fonts supplied by xmgrace were
replaced (in the cygport file) by a link to ghostscript's fonts, but
then those were replaced by URW fonts, which broke xmgrace.
OTOH the particular font files xmgrace is looking for are in yet another
place on Cygwin:
/usr/share/X11/fonts/urw-fonts
And indeed, making the /usr/share/grace/fonts/type1 symlink point there
does appear to fix the breakage.
So the minimal patch to grace.cygport (other than just leaving the type1
directory of xmgrace alone) would be:
$ diff -uwp grace.cygport{~,}
--- grace.cygport~ 2017-06-27 09:43:32.0 +0200
+++ grace.cygport 2020-01-28 00:08:56.345429500 +0100
@@ -78,7 +78,7 @@ src_install() {
rmdir doc
ln -sf ../doc/${NAME} doc
rm -fr fonts/type1
- ln -sf /usr/share/ghostscript/fonts fonts/type1
+ ln -sf /usr/share/X11/fonts/urw-fonts fonts/type1
popd
make_desktop_entry xmgrace Grace xmgrace
"Education;Science;DataVisualization;Motif"
An additional/changed dependency on the urw-base35-fonts-legacy package
would probably be needed, but I'll have to leave that to people who
understand Cygwin packaging.
--
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: grace broken installation
Am 25.01.2020 um 15:23 schrieb Rodrigo Medina:
Hi,
Both installations of grace-5.1.24 and grace-5.1.245 are broken.
/usr/bin/xmgrace.exe runs but gives the message:
--> Broken or incomplete installation - read the FAQ!
and then quits.
After reading the FAQ and comparing with a direct build from upstream
sources, I find the reason for that is that the FontDataBase file of the
distributed package is, indeed, wrong.
Apparently the type1 font directory supplied by grace was replaced by a
link to ghostscript's type1 font repository. But the FontDataBase
wasn't updated to match this change. This mismatch causes xmgrace to
baulk. This change was made between revisions 5.1.24 and 5.1.25 of the
cygwin package, which neatly explains why 5.1.24 works, but 5.1.25 does not.
For both versions the link grace-->xmgrace.exe is missing.
This was most likely caused by the cygport file not doing the (rather
unusual) 'make links' step of the original Makefiles, but rather doing
their own tweaking. The 'grace' link is only created by 'make links'
--- there is no 'grace' created in ${GRACE_HOME}/bin. I would consider
that an upstream bug, albeit it a small one.
--
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: Terminfo files not found?
Am 24.01.2020 um 00:31 schrieb Jim Zheng: I seem to be running into an issue with my terminal not being recognized after updating to the latest terminfo (6.1-1.20190727). Setting TERM to anything other than 'xterm' results in loss of terminal control where I am unable to use backspace/delete/text editing commands. WJFH Is anyone else running into this issue? I can revert to the previous version of terminfo and everything will work again, but after this long I'm surprised nobody else has brought this issue up. That's almost guaranteed because it's not been an issue for anybody else. -- 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: Version incorrect
Am 04.11.2019 um 23:06 schrieb Caines, Brian: > Hi, on the current website version it is listed as 3.0.7. However, when I > install it and right click on the terminal window -> Options -> About, it > says 3.0.6. You're looking in the wrong location. What you're looking at is the version of the _terminal_emulator_ (MinTTY). It even says so right there: "mintty 3.0.6". That is not by any stretch of things the version of Cygwin. That you would rather get like on just any U*ix or emulation thereof: uname -r -- 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: configure script fails during install (Setup Ver 2.897 (64 bit))
Am 04.11.2019 um 02:06 schrieb Lawrence Clooney: > Error Message: > checking whether to use NLS... no > checking for initscr in -lncurses... yes > checking ncurses.h usability... yes > checking ncurses.h presence... yes > checking for ncurses.h... yes > checking for Berkeley DB db.h version >= 4.1 ... no (version numbers not > found) > configure: error: Berkeley DB db.h is missing or has incompatible version No, that does not mean that the configure script failed. It means the configure script determined that your build machine lacks some capabilities this program needs, and thus refused to continue. As that's exactly what the script is supposed to do, it cannot be qualified as a failure. You will have to install the required packages to satisfy that dependency. In the case at hand, that would be libdb-devel (current version 5.3.28-2). What did fail here is either the sequence of instructions you followed (because they really should have told you to install that package), or your following of same (if they did tell you, but you didn't). -- 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: OPENMPI only works on Cygwin Terminal not windows Command Line
Am 27.10.2019 um 04:33 schrieb William John: > Dear Cygwin, > > I recently installed openmpi and libopenmpi-devel on my windows machine. > However, I cannot call mpicc on my windows cmd, rather I get "'mpicc' is > not recognized as an internal or external command, operable program or > batch file". That's not really surprising, given the following: $ ls -l /usr/bin/mpicc lrwxrwxrwx 1 hbbro hbbro 16 29. Mrz 2019 /usr/bin/mpicc -> opal_wrapper.exe* There are at least two problems with trying to run this from a Windows command prompt: 1) The file is a Cygwin-style symbolic link. Windows native tools haven't the slightest idea what that is, nor what to do with it. 2) The file name does not have an extension, much less one recognized by Windows command processors as executable (like .exe) -- 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: printf, "unable to initialize PRN" message
Am 11.09.2019 um 02:03 schrieb Blair, Charles E III:
> I have just installed cygwin (64 bit) and gcc. The "hello world" program
> works, but
>
> #include
> int main(){printf( "%c\n" , 'X' );return 0;}
>
> leads to
>
> Unable to initialize device PRN
> Unable to initialize device PRN
I suspect you've just rediscovered ancient knowledge, which dates back
as far as MS-DOS 1.x:
THOU SHALT NOT NAME THINGS "CON", "COM", "NUL" or "PRN"
Those names are reserved for DOS device drivers (similar to, but much
more pervasive, than Unix' /dev/printer' etc.)
--
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: looking for xcp and/or wxcopy?
Am 21.08.2019 um 21:39 schrieb L A Walsh: >> apropos cut|grep -iP 'copy|paste' > and found (among others) > wxcopy (1x) - copy stdin or file into cutbuffer > wxpaste (1x) - output a cutbuffer to stdout > xcb (1x) - X Cut Buffers - Pigeon holes for your cut and > paste se... > --- > but when I try to execute or find them they aren't > found. So have you run cygcheck on the packages that are supposed to contain them? "cygcheck -p wxcopy" tells me that the former are part of the WindowMaker package. xcb appears to not exist at all in current cygwin. So wherever that man page was picked up from, I suspect that's not even part of Cygwin. -- 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: More on Win7 update messing up HOME
Am 16.08.2019 um 15:28 schrieb David Karr: > On Fri, Aug 16, 2019 at 3:50 AM Andrey Repin wrote: >> Do you have %HOME% variable set in your user environment? >> Do you have %HOMEDRIVE%/%HOMEPATH% variables defined to something >> unsettling? > I checked "Environment Variables" in control panel, and I'm not setting > anything beginning with "HOME" in either user or system variables. That check is not really useful, though. You need to look at the actual environment constructed for a user process, at run-time. About the easiest is to start a Windows command shell (Start->Run "cmd") and look at the output of the "set" command. In cases of looking for names starting with some prefix, like here, you can narrow down the search: set HOME -- 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: Did I miss something? cscope v15.9.1 has been released ...
Am 10.08.2019 um 10:01 schrieb Houder: > Remarkably https://sourceforge.net/projects/cscope/ (news) > reports v15.8b as the last release ... > > ... though v15.9 is mentioned at a different tab (git). > > But really, what changed? (why NO annoucement?) That one's on me. I'm the maintainer of upstream cscope. There were some unfortunate events around the release of 15.9 which apparently distracted me enough to make me forget to actually post a NEWS item. I'll do that now (a bit over a year leater)... -- 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
Fixes for gcc-8.3 broke compilation with gcc-7.4
Hello one and all, As of commit b66dddb56d14a4032969fe8bb92d64baa6e0362e, winsup/cygwin/uname.cc no longer compiles with the current GCC version installed with cygwin itself. The newly added __attribute__ is unknown to GCC 7, and thus triggers a -Werror for unused/unknown attributes: $ LANG=C make c++wrap -O2 -g -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -mcmodel=small -std=gnu++98 -c -o uname.o ../../../../cygwin-clean-copy/winsup/cygwin/uname.cc ../../../../cygwin-clean-copy/winsup/cygwin/uname.cc: In function 'int uname_x(utsname*)': ../../../../cygwin-clean-copy/winsup/cygwin/uname.cc:28:58: error: 'nonstring' attribute directive ignored [-Werror=attributes] char buf[NI_MAXHOST + 1] __attribute__ ((nonstring)); ^ cc1plus: all warnings being treated as errors make: *** [../../../../cygwin-clean-copy/winsup/cygwin/../Makefile.common:41: uname.o] Error 1 -- 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: Wild card to address drives
Am 18.07.2019 um 10:03 schrieb Fergus Daly: > I have > none / cygdrive binary 0 0 > as the only line in the file /etc/fstab to allow for example > $ ls /h/config.sys > instead of the long-hand > $ ls /cygdrive/h/config.sys And that's precisely your problem. You've now overlaid two mount points onto /: the cygdrive tree, and the normal Cygwin root mount. Without this, your command would have worked just fine. > In Linux I can type something like > ls /?/ -Ax > as a wild card to address ALL drives, Not really, as there is no such thing as "drives" on Linux. The above will list all directories under / that have single letters as their name --- whether those be mounted filesystems, or ordinary directories. -- 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: cygport and C:\Windows\system32\tar.exe
Am 30.06.2019 um 07:37 schrieb Federico Kircheis: > My problem is that cyport tries to invoke tar with an absolute file, and > of course C:\Windows\system32\tar.exe does not understand a path that > begins with `/cygdrive/c`. No. Your problem is that you're trying to use cygport from the wrong place, causing the PATH seen by it to be completely wrong. Well, either that, or that you somehow failed to install Cygwin's own tar, even though it's part of the base system, so it should always be installed. Cygport, like many of the more involved utilities delivered by Cygwin, is meant to be used from inside the Cygwin shell. At the very least, you have to ensure that the PATH of the shell running cygport is set up properly, with Cygwin's `/bin' and/or `usr/bin' mounts at the front of it. > How do you generally solve that problem? Basically by not even having it in the first place. -- 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: Process argument passing problems
Am 21.06.2019 um 17:19 schrieb reiter.christ...@gmail.com: > Hey everyone, > > I have to following problem (using cmd.exe): > > C:\cygwin64\home\xy>C:\cygwin64\bin\echo.exe -DFOO=\"BAR\" -DBAR=\"FOO\" > -DFOO=\BAR" -DBAR="FOO" > > I would have expected: > > -DFOO="BAR" -DBAR="FOO" Expecting cmd.exe to parse command lines in anything resembling a sane way is, unfortunately, an exercise in futility. Microsoft allowed blanks in filenames with hardly any regard for the concepts of command lines and their parsing. We're still fighting with the repercussions now, 25 years later. > Context: I'm executing various cygwin programs through (native) Python and > passing C macros to gcc like 'gcc -DFOO=\"BAR\"' fails because of this. Are you sure Python even goes through cmd.exe to pass those command lines? If it doesn't, figuring out what cmd.exe does may be even less fruitful than it already is. > More background: https://github.com/msys2/MINGW-packages/issues/3548 Please note that that's about MSYS2, which, while closely related to Cygwin, is not really the topic of this mailing list. -- 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: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Am 06.06.2019 um 21:18 schrieb Hans-Bernhard Bröker: > Still that would constitut, if not a flat-out bug, at least severe > bit-rot in the upstream package, because if it doesn't work with > Cygwin's automake version 1.15, it most likely doesn't with reasonably > current versions of automake on other platforms, either. After some actual inspection, and a bit of RTFMing, things became clearer. There is indeed a general bug in the original source that requires fixing. The following line is sorely missing from the top-level Makefile.am: ACLOCAL_AMFLAGS = -I m4 It doesn't look like this should be buildable without that line, on any other platform. If it does, their gnome-autogen.sh must be rather different from Cygwin's. -- 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: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Am 06.06.2019 um 10:03 schrieb Soegtrop, Michael: > From a tarball. As far as I can tell I am exactly reproducing the > original package that is available as binary on Cygwin repos with > exactly the same sources, patches and cygport file. ... but possibly way different versions of the autotools compared to those the package was built with, back then. > I can't judge this and would need some advice here. The issue could > be at several places: > > - In the past and on other systems aclocal automatically included the > package local m4 folder in all process steps. Possible. Automake may have changed in that regard, at some point. Still that would constitut, if not a flat-out bug, at least severe bit-rot in the upstream package, because if it doesn't work with Cygwin's automake version 1.15, it most likely doesn't with reasonably current versions of automake on other platforms, either. > - In the past cygport automatically added an option to autoreconf to > include the local m4 folder. I rather doubt that. -- 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: Cygport: How to add -I m4 to autoreconf / aclocal?
Am 05.06.2019 um 11:53 schrieb Soegtrop, Michael: The reason is that aclocal is missing a "-I m4" option to include the local m4 subfolder. I wonder what I need to do in the cygport file to add this. Or should this be added in gnome2_autogen.sh. If that had to be done, that would constitute a clear upstream bug. Well, either that or that file itself should not be there. Are we building this from a tarball, or directly off the bleeding edge? "Autogen" scripts like that should usually only exist in Git/SVN/CVS versions of the source, but not in release tarballs. Those are supposed to be packaged with all autoconfigury already built and included, and the autogen script itself left out instead. > configure.ac:161: error: macro GTK_CHECK_BACKEND is not defined; is a m4 file > missing? > /usr/share/aclocal/ax_require_defined.m4:35: AX_REQUIRE_DEFINED is expanded > from... > configure.ac:161: the top level The name prefix AX_ indicates a non-standard macro. This particular one is available in the autoconf-archive package in Cygwin (hence the generic install location, instead of the version-specific ones where all our actual aclocal versions' files are kept). Linux distros may package it differently. But source packages using such non-standard macros may be assuming different versions of them than we have. Which is all the more reason they really have to include them, in their own version control. > I also wonder if the -install option to autoreconf shouldn't be forwarded to > aclocal. If autoreconf itself isn't doing that, we quite probably shouldn't, either. -- 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: The adventure of building Bedrock in Cygwin: any help would be appreciated
Am 20.05.2019 um 21:12 schrieb Jose Isaias Cabrera: > There is no configure script on the source directory, And that should have been a warning to you. This is the most portability-ignorant open source package I've seen in a long time, and by a very wide margin. They don't even _try_ to accomodate the notion that there might be anything else but Linux left under the sun. > so according to Bedrock [1] this is all I need to build it: Well, in all fairness, those are just the instructions for one type of Linux distribution. There are others, but those would not get you any further, because they just care about different extra libraries, whereas the real problems are in how they configure the compiler and its standard library. Among the fallacies they evidently subscribe to is the one that one should force-feed the '--std=c++14' flag into all compilations, to get support for C++ 14 language features, without bothering about the effects that will have on the standard library feature selection process. At the very least, they should have use '--std=gnu++14' instead, to keep the libraries full-featured. Or if they didn't, they would have to add some feature activation options like '-D_GNU_SOURCE' to get back what they so wilfully turned off. In short, this whole source is doomed to fail utterly on any system whose C standard library is not GLIBC. -- 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: Why is __unix__ defined, and not __WINDOWS__ ?
Am 12.05.2019 um 20:22 schrieb Agner Fog: > I have noticed that the gcc and clang compilers have defined the > preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 > when compiling a windows executable. > > Why is this? Because it's correct that way. Cygwin runs on Windows, but it _is_ not Windows. > A C/C++ program will check for these macros if it wants to know which > operating system you are compiling for, and this will give the wrong > result. No. It gives the correct result. -- 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 bash script removing equal sign
Am 25.04.2019 um 18:11 schrieb Peter Palaparthy: > Cygwin bash script is removing equals sign from command call. On what basis did you conclude it was bash doing that, and not, say, make? > *Here is the relevant command in my makefile.* > *$(elabcmd) = $(XELAB_DEFAULT) \-generic VERSION=10* I believe for that to be a syntactically valid line in a Makefile would take some more Makefile code on top of it. If you don't show the actual file you use (or a suitably trimmed, yet self-contained abstract of it), you're making it impossibly hard for people to help you. > *compile:$(elabcmd)* Same problem here. signature.asc Description: OpenPGP digital signature
Re: bug: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
Am 25.04.2019 um 17:48 schrieb Eric Blake: > On 4/25/19 10:28 AM, Brian Inglis wrote: >> Would it be allowed and valid to #define MSG_EOR 0 to simplify lack of >> support? > > No, because that implies that EVERY send() call is requesting MSG_EOR > and that it never fails. And maybe more importantly, it's explicitly required to be non-zero. -- 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: cygwin-devel v3.0.2-1 socket.h does not #define MSG_EOR per the POSIX standard
Am 24.04.2019 um 19:54 schrieb Eliot Moss: > On 4/24/2019 12:43 PM, Corinna Vinschen wrote: >> Since MSG_EOR isn't implemented in the underlying transport layer, >> there's no way to implement it in userspace. That's why it's not >> defined in Cygwin's headers. If you have an idea how to implement >> this in plain userspace, feel free to provide patches. > > I don't have a direct interest in this issue, but I do have a wondering. > If Cygwin fails to define an error code -- even if the error cannot > actually happen under Cygwin -- isn't that a problem when trying to > compile imported software? That, like the question whether Cygwin is in any way obliged to define it, ends up in an issue of Interpretation of Standardese. The latter is a language that looks deceptively much like ordinary English, but just like Legalese, is not the same thing. In the case at hand the point that needs interpretation is what that parenthesis "(if supported by the protocol)" really means. What is "the protocol" it refers to? What if several protocols are supported, which differ in support for this? The core issue, though, is: what is controlled by this "if", i.e. what is the "then" effect? And what's the "else"? Cygwin's interpretation (whether by design or by accident) is: if this never is true, the "shall define" a few lines above does not apply any more. If that's a correct interpretation, then source code would be wrong to just assume presence of this macro unconditionally. In that case the actual problem that software noticing would be written incorrectly (they should #ifdef MSG_EOR before using it). An alternative interpretation could be that this entire parenthesis is ultimately just a superfluous that adds no meaning to the standard; the macro would have to be defined always; software would be entitled to blindly assume its existence, and Cygwin would be wrong about this. Either way, as Standardese goes, this is sufficiently unclear that it IMHO calls for a defect report to the governing body of this standard. -- 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: DJGPP cross compiler crashes.
[A side note, first: this is a traditional mailing list, i.e. the policy is snipping and bottom-replying...] Am 19.04.2019 um 01:41 schrieb Carlo B.: > I have no idea how you can run it without errors, please note that > i586-pc-msdosdjgpp-gcc works fine until it does not link. Please note that this quite probably means that it's not the compiler package itself that's causing you grief, but rather djgpp-binutils. Or it could be the runtime base package. So: did you run cygcheck -c on your djgpp packages? Check if getting them from a different cygwin mirror changes anything? Have you tried adding options to the gcc command line to see what it's actually doing in some more detail, like '-v' or '-Wl,-v'? I checked on Win10 Home, originally just 64-bit. I've had these packages installed for years, and they haven't changed since, so there's not really any good reason to assume they should suddenly be broken this week. And at least from what I'm looking at, they aren't. Just for making extra sure, I just added DJGPP to the Cygwin-32 installation on the same machine, and again, it just worked without a hitch. -- 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: DJGPP cross compiler crashes.
Am 18.04.2019 um 16:11 schrieb Carlo B.: > I would like to signal that the DJGPP cross compiler, included into > the available packages, crashes as soon as you try to compile > something with it. Doesn't, here. It just works. -- 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: tar cygwin64/ from old to new computer?
Am 26.11.2018 um 21:32 schrieb Gilbert St. Firmin: > Could the native Windows version of 7-zip be used on both old and new > computers? Possibly. If that can be taught to copy all the attributes used by Cygwin, without running into the usual problems we see whenever Windows tools are used to handle those. But I really very much doubt it. This really is a full blown chicken-and-egg situation: the only tools really known to be able to correctly copy Cygwin files including all their ACLs are Cygwin itself, and its installer. All other tools are suspect. It all comes back down to what I wrote in my initial answer: is remote access to a Cygwin mirror server really so much slower than your local network that there's even any gain to be had from going this untested route? I.e. why even risk this? -- 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: tar cygwin64/ from old to new computer?
Am 25.11.2018 um 15:38 schrieb Lester Ingber: > I'd like to simply transfer my cygwin64/ directory from my old Thinkpad > to my new Thinkpad, both running Win 10 x64 Pro. E.g., I would put my > old c:/cygwin64/ onto a flash SSD USB drive e:/ . > cd c:/ > tar cfp - cygwin64 > e:/cygwin64.tar & > Then e:/cygwin64.tar would be mounted on my new computer. You're overlooking a chicken-and-egg problem there: your new computer has no 'tar' to unpack that file. > I'm assuming that there is not actual install required, e.g., having to > run setup-x86_64.exe first on the new computer? That assumption is incorrect. If your in-house network really is so significantly faster than outside internet that this makes a difference, what you can usefully copy over from one machine to the other would be setup.exe's package cache directory tree. Other than that, there's really no workable short cut compared to simply running setup. -- 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: urgent help for tool
Am 24.10.2018 um 22:49 schrieb Andrey Repin: > Greetings, Stefan Baur! > >> if you can either get hold of the current mailing list's subscriber >> list, to auto-subscribe everyone to a new list, or you are able change >> the current mailinglist's address to, say, cygwin...@cygwin.com, you >> could set up an autoresponder at cygwin@cygwin.com instead. > > That's a long shot, but… given the increased traffic of this noise, it may be > an option. A less disruptive approach would be just a) switch this list from anybody-can-post to subscribers-only, at least for the time being, and then b) put the FAQ pointers about FAST_CWD prominently into the auto-reply for non-subscribed users. At the very least this would have the benefit of not breaking the continuity of the mailing list archives. All this based on two assumptions I cannot vouch for: 1) that ezmlm even has the requisite functionality 2) that totally uncontrolled access to the primry mailing list is not on someone's list of non-negotiable requirements -- 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: Distributing program compiled with gcc on Cygwin to Windows users
Am 14.10.2018 um 23:20 schrieb hacker...@protonmail.com: > Hello, > > I have a program that uses X11/Motif and runs fine, within Cygwin/X on the PC > it was compiled on. > > What is the *minimum* required set of Cygwin libs and any other files I need > to distribute along with, it to end-users who may just have Windows (and not > Cygwin) installed? I'm reasonably sure that that minimum set would effectively have to be an actual Cygwin installation. You'll need an X server, and that requires a pretty complete Unix tool environment. And that Cygwin environment will generally not transfer successfully from one machine to another by just copying files. You really have to run the Cygwin setup program. And that's before we consider what might happen to users who actually _do_ already have a Cygwin installation on their machines. Are you prepared to explain to them why you interfered with those? -- 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: Creation of weird WINDOWS-related (sub)directories
Am 25.09.2018 um 17:16 schrieb Fergus: Unintentionally I have confounded the discussion. The directory named "consoleX" is my home-grown Cygwin root directory. (Others' preferred locationname might be "cygwin" or "mycygwin" or whatever.) That does not explain anything, actually. Cygwin's own root directory is always '/'. The one you speak of would be the windows-side installation root directory (c:\cygwin or c:\cygwin64 by default), but that would never show up like that from inside cygwin. I.e. while you do have c:\consoleX\bin that will not show up as /consoleX/bin but rather as /bin or /cygdrive/c/consoleX/bin The directory %SystemDrive% occurs at the root of the Cygwin filesystem. I cannot work out what activity has triggered it .. .. A look at the creation time of the directory might provide insightful. -- 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: Why does -std=c++11 hide certain function calls
Am 05.09.2018 um 07:55 schrieb John Selbie: With this: g++ foo.cpp -c -std=c++11 It compiles fine everywhere else, except CygWin. Output on Cygwin: I'm afraid that may mean everywhere else is wrong. Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the command line line works. But I don't understand why the need to enforce these extensions to get access to some of the most common unix libraries? Because that's what std=c++11 is meant and documented to do. It turns off all extensions to the standard language. And yes, that does include extensions to the standard libary, up to and including POSIX-specific content. For what you want to do, std=c++11 is simply the wrong setting. -- 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: Advice on setting Cygwin build parameters for OpenSC.
Am 02.09.2018 um 03:22 schrieb Darren Whobrey:
The tweak required to get OpenSC to work with the standard Cygwin
utils, like ssh-agent, is to comment out a line in the configure.ac
script that previously was causing it to force a WND build, which
resulted in struct packing of 1 – and that doesn’t work with the ssh
utils distributed with Cygwin. For details see the end of thread
here: https://github.com/OpenSC/OpenSC/issues/607.
That line is flat-out wrong. Delete it. You're already in a
--host=*cygwin* specific section of your configure.ac script, so there's
no further precautions to be taken.
While at it, you may just as well delete the entire "with_cygwin_native"
branch (lines 100..105), because that has been un-applicable for years.
Building for native windows (i.e. MinGW) is has long since stopped to
be done by a -mno-cygwin flag. Instead you would pass the configure
script a --host={something with mingw in it} flag to initiate a proper
cross-build, and that will bring you into the existing --host=*mingw*
case abvoe.
The question is, what is the most sensible way to update the
configure.ac and still support other Cygwin users that may be using
mingw or other toolchains rather than gcc?
Checking for GCC is almost certainly a red herring here.
should be to not include the offending line, but then that would
break WND builds.
Not really, because whatever you mean by "WND builds", they won't be
ending up in that cygwin case.
--
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] mingw64-{i686,x86_64}-gcc-7.3.0-1 (Test)
Am 25.08.2018 um 02:13 schrieb Steven Penny: On Fri, 24 Aug 2018 10:11:42, JonY wrote: $ wc -c /lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a 22446354 /lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a $ wc -c mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/libstdc++.a 5597192 mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/libstdc++.a And it is of course totally out of the question that this difference could be caused by these being different major versions of GCC, right? -- 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 DEFECT: Basic cygwin Update Fails to Complete
Am 25.07.2018 um 20:50 schrieb Brian Inglis:
If you use a Cygwin shell you can see /usr/{bin,lib}/, etc.; if you use a
Windows shell you can not.
That's got nothing to do with the shell. It only depends on whether the
program that does the "seeing" is a cygwin-based one or not. From a
plain CMD.exe:
C:\>\cygwin\bin\ls -l /usr
total 360
drwxr-xr-x+ 1 hbbro hbbro 0 Jul 4 00:15 bin
drwxr-xr-x+ 1 hbbro hbbro 0 Nov 29 2017 i686-pc-cygwin
drwxr-xr-x+ 1 hbbro hbbro 0 Nov 29 2017 i686-w64-mingw32
[...]
--
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 DEFECT: Basic cygwin Update Fails to Complete
Am 25.07.2018 um 12:39 schrieb John Delaney: As I have done many times before, I attempted to update my 32-bit Cygwin installation around midnight 7/24-25/ 2018. This time the process failed at about 99% complete. " /etc/postinstall/ texlive-collection.basic.sh" failed to complete repeatedly and consistently. "Failed to complete" or did it actually report and error and terminate? If the former: how long did you give before you decided it would never finish? "/usr/bin" does not normally exist on Cygwin installations. Whatever gave you _that_ idea? -- 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: Windows upgrade
Am 13.06.2018 um 01:30 schrieb Alejandro Benitez: It's somehow clear I thankfully won't need to upgrade to cygwin64 until later, While you don't need to do it, you'll have to re-install Cygwin anyway, and frankly, installing 32-bit Cygwin from scratch, on a 64-bit Windows machine, just seems excessively nostalgic. You're already removing so much cruft --- why let yourself be tied to the past by sticking with 32-bit Cygwin? I mean it seems I'll be able to still use my 32 bit cygwin after I upgrade to 64 bit Windows 10, Unlikely. You'll have to do a complete re-install to fix up all the file permissions and regsitry entries. -- 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] __wait_status_to_int() is expected to be a macro
Am 08.06.2018 um 17:16 schrieb Denis Nikiforov: /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error: non-constant condition for static assertion static_assert(!WIFEXITED(still_active), "Internal Error"); ^ __wait_status_to_int must be a macros but it's redefined as a function. It must? Says who, based on what standard document? For starters, nobody gets to make any such claims about __wait_status_to_int(), because that's an internal implementation detail of Cygwin. If at all, such a claim might be made about WIFEXITED(), which is a POSIX standard element. But POSIX makes no such requirement, as far as I could see on short examination. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC 7.3.0 -std=gnu++17 failed to getline() from std::ifstream
Am 05.06.2018 um 17:56 schrieb Ivan Shynkarenka: Hello, I found an issue with Cygwin GCC 7.3.0 when building with -std=gnu++17 flag. Using Cygwin 32-bit or 64-bit? I have to ask because I could not reproduce your problem here, on the 64-bit version. Build: g++ -std=gnu++17 test.cpp Builds and runs fine, here. And what version of things do you have, anyway? If you had followed the advice at https://cygwin.com/problems.html, we would already know that... -- 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: Defaulting to stabs debug output from AS Cygwin64
Am 15.05.2018 um 19:17 schrieb Michael Enright: The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using -gdwarf2 with assembly code manually or through gcc is successful in producing a Cygwin64 executable that Cygwin64 GDB can work with. This combination of circumstances led me to wonder how stabs was chosen for Cygwin64. Basically because it was not chosen. It's not even actually supported, as evidenced by those relocation failures: not how those occurred in the .stab section. "The" default of Cygwin is whatever the compiler uses, i.e. Dwarf2, and was indeed chosen, because none of the older formats stand a chance of really handling the amount and complexity of debug information needed for modern-day C++. On to of that, making '-gdwarf-2' the default -g mode for 'as' would be an exercise in futility anyway, because that option is essentially a no-op. That's because Dwarf-2 debug information is _not_ actually created by the -g flag to begin with: it's spelled out by the compiler as reams of data and reloc statements, to go into specially named sections like '.debug_info'. GCC doesn't even pass any '-g' flag to the assembler in its default -gdwarf-2 mode. It makes sense that "as -g" equals "as -gstabs" because unlike the other ones, that one at least does something: it causes .def pseudo-ops to put data into the .stab section, which also is automatically created by that option. In a nutshell: you don't want to use either of "as -g" or "as -gstabs" -- 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: /usr/include/ssp/wchar.h:78:1: error: unknown type name ‘FILE’ (during cygport package build)
Am 13.05.2018 um 18:01 schrieb waterlan: The C flag that triggers this option is -Wp,-D_FORTIFY_SOURCE=2. That does look rather weird. Why would one write that instead of just -D_FORTIFY_SOURCE=2 ? Anyway, the test can be simplified quite a lot to: hbbro@NB4 ~/tmp $ cat twchar.c #include $ gcc -D_FORTIFY_SOURCE=1 -fstack-protector-strong -c twchar.c -O2 -D_XOPEN_SOURCE In file included from /usr/include/ssp/wchar.h:5:0, from /usr/include/wchar.h:336, from twchar.c:1: /usr/include/ssp/wchar.h:78:1: error: unknown type name 'FILE' __ssp_decl(wchar_t *, fgetws, (wchar_t *__restrict __buf, int __wlen, FILE *__restrict __fp)) ^ /usr/include/ssp/wchar.h:78:1: error: unknown type name 'FILE' __ssp_decl(wchar_t *, fgetws, (wchar_t *__restrict __buf, int __wlen, FILE *__restrict __fp)) All four of the GCC options have to be there to trigger this (_FORTIFY_SOURCE can be set to 2, for the same result). Basically the SSP additions to fail to compile, but only if the feature set has been restricted from the default by -D_XOPEN_SOURCE. Ultimately this happens because the latter disables the typedef of FILE in /usr/include/wchar.h line 72 ff: #if __POSIX_VISIBLE >= 200809 || _XSI_VISIBLE /* As in stdio.h, defines __FILE. */ #if !defined(__FILE_defined) typedef __FILE FILE; # define __FILE_defined #endif #endif I don't know remotely enough about this SSP stuff to judge if that's even supposed to work in -D_XOPEN_SOURCE mode. But as it is, it can't. -- 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 2.8
Am 08.05.2018 um 13:22 schrieb David Spencer: Morning, I am trying to get CYGWIN Version 2.8, this is the only version approved for our system at present, Providing that is, to a great extent, actually the job of whoever approves versions of Cygwin for you. That's because the version number of cygwin itself barely begins to define an actual fixed configuration of the whole Cygwin environment you'll be installing: that's _one_ package whose version number has been nailed down, but _hundreds_ of others left totally floating. The only practical way of defining an installation of which it can even make sense to call it "approved" is to host a fixed mirror repository that's controlled by whoever does the approving, inside the organization that requires said approval. -- 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: Floating point exception in strtod()
Am 08.04.2018 um 05:11 schrieb Duncan Roe: I tried in 64-bit with the same result as Eliot: works fine w/out feenableexcept, no o/p with feenableexcept. Just in case this may have been overlooked: please note that "no output" actually means the program crashed because of an uncaught SIGFPE, just like the 32-bit version does. The only difference between 32-bit and 64-bit versions of the program is that the 32-bit one outputs the "core dumped" message and writes a stackdump, whereas the 64-bit one just dies without _any_ detectable symptoms: no message, no stackdump file, nothing. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to handle length limit of PATH environment variable
Am 05.04.2018 um 11:19 schrieb Peter Bauer: i was bitten by the length limit of the PATH variable of 4095 characters (see [1]) and could not find a way around it. This means i have a lot of software packages in different directories and each of them adds itself to the PATH so one can run the executables and have the shared libs available. As far as DLLs are concerned, that would be a misuse of the PATH. AFAIK they will already be found by being in the same directory as the executable that needs them. Under Windows there is the "short path workaround" but what to do under Cygwin? Being Cygwin, you should do what Unix has always done: do away with the whole idea that every program needs an entire directory tree of its own. The promise that this would somehow make separate installation and, more importantly, un-installation or update of program packages much easier was never really kept, anyway. I.e. you shoule have _one_ tree like thone below /usr, instead of dozens of c:/programs/manufacturer/package trees. And while maintaining such a collection on Windows might seem nightmarish, tools like "stow" make it quite manageable on a Unix-style platform, with Unix-style software packages. With stow, it works like this for a typical autoconf'ed package: .../configure --prefix=somewhere make make install prefix=somewhere/.stow/packagename pushd somewhere/.stow/ stow packagename popd Stow then builds and maintains a thicket of symlinks from "somewhere" into the individual packages' trees under "somewhere/.stow" such that the packages work just as if they had actually been installed directly into "somewhere", while they're still separate and can be updated or uninstalled individually. Sometimes package have to be massaged bit (e.g. for GNU info 'dir' files), but it works remarkably well given how simple it is, at heart. -- 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: mandb -p deleting "obsolete" Windows cat directories
Am 23.01.2018 um 02:49 schrieb Brian Inglis: I was surprised when I looked at the log (attached, with lots of man directory > indexing stripped), that mandb -p decide to scan my C drive and perform the It probably wasn't actually scanning "the C drive" as such, but rather the neighboring directories of those listed in your $PATH to discover further worthy additions to $MANPATH. And since %windir% and %windir%\System32 are on the default Cygwin $PATH... -- 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: setup's response to a "corrupt local copy"
Am 13.12.2017 um 14:28 schrieb Ken Brown: When setup is preparing to download files and it finds a corrupt copy in the local cache, it issues a fatal error message telling the user to remove the corrupt file and retry. Steven said that setup should silently delete the corrupt file, while I argued in favor of the current behavior, on the grounds that setup shouldn't be deleting user files if it doesn't know where they came from. I agree with the latter approach, primarily because those files must have still been OK the last time setup was run successfully, or not have been there at all. Otherwise this run of setup wouldn't be the one where this suddenly popped up, would it. So the real question is: how could that status have changed from then to now? First off, I hope we agree that files very rarely change their content just by lying around somewhere, particularly in a local cache folder structure like this, which will usually not be touched by anything other than setup itself. So the odds should really be negligible that the files just corrupted themselves. If those are sizable odds on a given machine, the ease of further cygwin installs done onto it are the least of your worries. That leaves two primary possibilities how this change of state might have occurred: 1) File contents changed on purpose, probably by manual overwrite with locally built archives. 2) setup's idea of what a correct file is changed from one run of setup.exe to the next, mostly likely by loading a newer setup.ini There is a middle ground: setup could query the user. Additionally, as suggested by cyg Simple, there could be an option that directs setup to silently remove corrupt files. I agree: this is essentially the same situation as a merge conflict in CVS/SVN/git: upstream (setup.ini) and local working copy (archive) are now in conflict, and you really _have_to_ ask the user about what to do about it. The query should contain relevant details (CRC expected vs. observed, timestamps, whatever) to allow the user to make an informed decision, and it might better offer an extra wide selection of answers, such as Back to selection, Delete this, Delete all, Keep this, Keep all, and possibly even "Back up local file for later inspection". A command line switch really won't do, because its setting would be decided either way too early or slightly too late for that decision to have any reliable relation to what the user needs to happen in the case at hand. It would unavoidably trigger irate user feedback like "This switch solved some arcane problem I don't even remember any more, years ago, so I hardcoded it in the start script; and _now_ you tell me that's what killed my local, irreplacable cygwin packages?" one way, or "If just some junk file needed to be deleted, why on earth does that mean I have to step through that entire, tedious setup and package selection _again_!!??!@" the other. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to use CMake with cygwin/mingw toolchain?
Am 20.10.2017 um 14:50 schrieb Peter Quiring: The mingw versions have x86_64-w64-mingw32- or i686-w64-mingw32- added to their exe names. Currently I just use these directly but I want to use cmake. You can just tell cmake to use them: cmake -D CMAKE_C_COMPILER=x86_64-w64-mingw32-gcc But for the full story, you should really read the "cross compiling" chapter of cmake's documentation. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC-6.4 sys/select.h build failures with std=c++14
Am 26.09.2017 um 07:32 schrieb Marco Atzeri: "The header shall define the fd_set type as a structure." so if they are using it, they should have a proper include The complete story is a bit more complicated than that, though. The curl maintainers almost fixed this at their end, but then Cygwin reverted part of a change that had "suddenly" triggered their broken code to actually fail before they did. Before then, Cygwin's fd_set was actually in , which was then #included by . The change was to define them it where it belongs But then the second change was made (commit ee97c4b22491b205fd3b7697e03c909e02b652d3), which reintroduced # if__BSD_VISIBLE #include in . This actually re-introduced a part of the original POSIX violation in Cygwin: #including will, again, drag in even though that was not asked for. Apparently this violation is sufficiently wide-spread that there's quite some code out there that relies on it. Curl is in this group. All this seems to have left the Curl people under the impression that there was nothing wrong with their code, but that rather Cygwin was broken, and for a relatively short time only, too (2015-12-17 to 2016-03-18). The fragment in question is positively hideous: #if defined(_AIX) || defined(__NOVELL_LIBC__) || defined(__NetBSD__) || \ defined(__minix) || defined(__SYMBIAN32__) || defined(__INTEGRITY) || \ defined(ANDROID) || defined(__ANDROID__) || defined(__OpenBSD__) || \ (defined(__FreeBSD_version) && (__FreeBSD_version < 80)) #include #endif Now people complain about autoconf being clunky, but it's easily an order of magnitude better than _that_ pile of nonsense --- particularly given the fact that they actually use autoconf to build their code. They just don't do so in their public, installable header file. -- 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] mingw64-{i686,x86_64} binutils, gcc (Test)
Am 25.09.2017 um 20:44 schrieb Steven Penny: perhap you are using old versions Not exactly. I'm using the current versions: 2.25.0.1, 5.4.0 respectively --- you're using not old enough, a.k.a. still "Test"ing versions ;-) -- 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] mingw64-{i686,x86_64} binutils, gcc (Test)
Am 25.09.2017 um 03:53 schrieb Steven Penny:
On Sun, 24 Sep 2017 00:48:20, JonY wrote:
I don't really work with cmake, but what it looks like, but it probably
makes gcc look in the mingw include dir first and then gcc's, breaking
gcc's headers.
Correct thus far. -isystem is really not a compiler option that CMake
should be injecting on its own recognizance. It's for specs files,
compiler/libc implementation control and such. It will almost certainly
break, among other things, any non-trivial use of #include_next.
Here is another problem:
$ cat z.cpp
#include
main() {
std::cout << "cout test\n";
}
$ x86_64-w64-mingw32-g++ -static -o z z.cpp
$ ./z
Segmentation fault
Does not reproduce here.
--
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
