I use and love cygwin, but every few weeks it notifies me that a new installer is available and I should use it to get the latest bugfixes. But I find this quite annoying because of my company policy, where downloading, installing and running a new .EXE file is a bit of a process due to paranoid company monitoring software.
I am just curious why the installer updates so frequently and what will happen if I don't update it. It is after all just an installer - all it does is it downloads updated packages and installs them (or rather, that is what I believe all it is doing). I do not understand why such a simple tool should have so many fixes/updates over time. If I don't update the installer, will I miss out on updates to the cygwin packages themselves?
I have been using the same cygwin version since years now and not faced any issues.If the application is working as expected then you dont need an update unless you face some trouble or you are migrating to a new windows Os which might have some compatibility issues.
Note : There is no guarantee that there will not be any problems with applying updates and also the cygwin faq section says that after updates issues should be reported to the project or product supplier for remedial action.
https://cygwin.com/faq/
The changes in Setup are usually to improve the functionality or correct some
issue.
See relative Announce:
https://sourceware.org/pipermail/cygwin-announce/2021-April/010021.html
Most of the time, previous version continues to work fine.
Broke of compatibility is very rare.
Related
Hi we are currently using Quickbuild for our Automation Jobs,apparently as we tried to deploy some changes we are unable to proceed due to this:
Does anyone know how to fix this? I have tried updating our git version to the latest, and I have also tried to install a cygwin latest version, none of this has solved our problem.
https://www.cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
4.45.
How do I fix find_fast_cwd warnings?
Older Cygwin releases asked users to report problems to the mailing list with the message:
find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report
this problem to the public mailing list cygwin#cygwin.com
Recent Cygwin releases changed this to the message:
This typically occurs if you're using an older Cygwin version on a newer Windows.
Please update to the latest available Cygwin version from https://cygwin.com/.
If the problem persists, please see https://cygwin.com/problems.html.
This is not serious, just a warning that Cygwin may not always be able to exactly emulate all aspects of Unix current directory handling under your Windows release.
Unfortunately some projects and products still distribute older Cygwin releases which may not fully support newer Windows releases, instead of installing the current release from the Cygwin project. They also may not provide any obvious way to keep the Cygwin packages their application uses up to date with fixes for security issues and upgrades.
The solution is simply downloading and running the Cygwin Setup program, following the instructions in the Internet Setup section of ``Setting Up Cygwin'' in the Cygwin User's Guide.
Please exit from all applications before running the Cygwin Setup program. When running Setup, you should not change most of the values presented, just select the Next button in most cases, as you already have a Cygwin release installed, and only want to upgrade your current installation. You should make your own selection if the internet connection to your system requires a proxy; and you must always pick an up to date Cygwin download (mirror) site, preferably the site nearest to your system for faster downloads, as shown, with more details to help you choose, on the Mirror Sites web page.
The Cygwin Setup program will download and apply upgrades to all packages required for Cygwin itself and installed applications. Any problems with applying updates, or the application after updates, should be reported to the project or product supplier for remedial action.
As Cygwin is a volunteer project, unable to provide support for older releases installed by projects or products, it would be helpful to let other users know what project or product you installed, in a quick email.
I am trying to develop a simple windows GUI in go (first attempt).
After considering a few packages to get me started, I landed on this https://github.com/lxn/walk and it seemed ideal. I cross-compiled from my ubuntu laptop and the provided demo worked on all target platforms (win7/8/10)
The problems came when I tried to start developing from my linux laptop - initially in atom, but I've since tried with sublime, emacs and phpstorm and noticed an issue with go get (so I'm guessing it's the underlying go tooling that's failing)
The first error I'm seeing is:
/../github.com/lxn/walk/tooltiperrorpresenter.go:8: undefined: ToolTip
This affects development across all affected IDEs tested:
disables autocomplete
halts linting
cant test
gofmt worked in some (perhaps tool ordering)
affecting any file referencing this lib.
And this is the first of many errors which seem to be due to the library importing its internal win package which contains files which are marked with the flag:
// +build windows
I cunningly decided to start ripping out these tags from the lib - hoping that would at least allow me to get on with development, but then I started seeing new errors regarding too many arguments being passed to syscalls in the win package - presumably because the different platforms (win/nix) have different numbers of parameters in those syscalls.
I then tried marking everything with the //+build windows flag, but the parade of errors remained unchanged.
I found some issues on the project github which are related:
https://github.com/lxn/win/issues/26 : no buildable Go source files
and there are solutions for "go getting" the files but none so far for my IDE woes.
I've also seen this type of issue in some other windows specific go libraries so I don't think it's an issue for the package author. But I would be interested to hear any solutions from a code architecture perspective if they exist
I haven't actually tried doing this from a windows VM yet (I presume that would solve the issue from my end) - but its a bit of a jarring solution as I'm already juggling vms to test the app so I'm keen to find another way.
TLDR:
Do I have to work from Windows machine / vm in order to have a fully
functional IDE when developing for windows from linux or is there a way to satisfy the go tooling
I'm installing Visual C++ Redistributable 2013 as a prerequisite (if its not installed)through my installer. But sometimes already installed VC++ is corrupted then my installer does not work because I'm having DLL functions called in CustomAction.
So my question : Is there any way to find whether the installed VC++ redistributables is corrupted or not ?
Health checks in general are a pretty difficult topic. For files built into Windows, there are tools like SFC, but that doesn't extend to other installed packages. For MSI packages, you can choose to run repair, and in some cases Windows will do this automatically; this topic in general is called Resiliency. But unless auto- or manual-repair fixes the sorts of problems you encounter in the wild, it's not very relevant.
So the question becomes what sorts of problems do you actually encounter, with what frequency, what their fix is, and what problems can be caused by attempting to fix them. If it's sufficient to invoke a manual repair of the VC++ redist, that's fairly easy to implement. If a full uninstall and reinstall is required, that's much more invasive; the idea of making that part of an installation rubs me the wrong way. If you have to do this only in very specific situations, it may depend on how well you can identify those situations.
Alternately, if your focus is ensuring that your installation succeeds, you may be able to statically link your custom action DLLs so that they no longer depend on the state of the VC++ package. This will not help your application much if the application also depends on the VC++ package, however. Perhaps a privatized copy of the VC++ DLLs can address that (if the 2013 version supports that--I forget), at the cost of more difficulties servicing your copy of the VC++ DLLs in case of security updates.
But again, this all depends on what sorts of problems occur, whether they're frequent enough to merit addressing them, and whether the cure is worse than the disease.
Hi I have a Windows OS and I currently have the most up to date version of Node.JS running (which includes npm). I would really like build and compile 0.1.91 which can be found here http://nodejs.org/dist/. I'm extremely new to this and any all help would be greatly appreciated.
Node first supported native Windows builds in the .5 dev branch. To make it happen, they had to rewrite many internals from scratch – the platform compatibility layer now exists as libuv.
Before that, you had to build Node under Cygwin. I remember building .4 in Windows with Cygwin, and it was a complete pain. The GitHub wiki has since pulled down all Cygwin-related information since it's no longer relevant. (If you really want to see how Cygwin builds were done, I suppose you could clone the wiki's repo and go digging around. The information isn't available online anymore.)
Support for building on Windows with Cygwin wasn't added until 0.1.98, and support was dropped with .6. So, the specific version you're trying to build won't work.
At any rate, it's a very bad idea to run very old software, especially something like Node 0.1, which was still very early in its development. It's nearly guaranteed to be full of security holes.
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.