This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Anecdotal: Rebase and Visual Studio 2015 and /etc
- From: "KARL BOTTS" <kdbotts at usa dot net>
- To: <cygwin at cygwin dot com>
- Date: Wed, 29 Jun 2016 07:24:05 -0500
- Subject: Anecdotal: Rebase and Visual Studio 2015 and /etc
- Authentication-results: sourceware.org; auth=none
- Z-usanet-msgid: XID955uFCmyF5264X33
A couple of weeks ago I installed Visual Studio 2015 (aka VS14) onto a machine
that was already running Windows 10 and had VS2013 (aka VS12) on it. The
machine was once updated from Windows 7, but that was months ago, had been
fine. It is a huge install -- 20GB disk space, more than an hour, a couple of
reboots.
After that, I had the now semi-familiar problems with cygwin -- "cannot fork,
cannot load dlls", that kind of stuff.
I went thru several variations of the rebase procedures, following various
advice on cygwin web site, and emails from this list. I could not get cygwin
back to fully normal.
Eventually, I reinstalled a fresh cygwin, right after a reboot, rebooted
again. Now all has been good for a couple weeks.
I have a couple of anecdotal impressions, from this experience and others:
1) After you do the full rebase, before you even start anything cygwin, reboot
Windows, then start a bash or something. Reboot Windows, early and often,
whenever upgrading anything. This has helped me before. I suspect that I
forgot it this last time. I _suspect_ that had I followed that, I would not
have had to reinstall cygwin. Maybe.
2) I always have cygdrive-prefix set to /, so that I can do, e.g. "cd /c".
But when you reinstall cygwin, you must do it again with "mount -c". And then
immediately do "mount -m > /etc/fstab", so that it sticks. Then, you should
patch up the symlinks in /etc/{hosts,services,couple-more}; find them with
readlink. There are some more in some fonts dir, but I ignore those: don't
care.
3) Once you have a cygwin you like, you can _usually_ copy it to other hosts.
Use cygwin cp or tar. Do not use XCOPY: does not handle links right.
ROBOCOPY can be used in a pinch. What goes wrong, maybe one time in four, is
rebase troubles: goto (1). Once you know you can copy cygwin from host A to
host B, you can generally do it again, to keep cygwin up to date across hosts.
I _think_ that once you have a DLL-load-address compatible install of cygwin
across several hosts, you can freely copy between them.
4) Keep yourself a list of cygwin packages you know you need, keep it small if
you can. Makes a cygwin install much easier. I have maybe 30. I just enter
then in to the cygwin-setup GUI: is painful, but reliable. I have had trouble
with the "setup -P", sometimes, but I think you could get that to work.
5) Again, reboot Windows between any steps. Maybe not always necessary, but
can't hurt: you want to know that it _will_ reboot, anyhow. And, it moves
DLLs around, even installs more, on the way back up. You want to be sure it
has done all that.
6) Once you get this all working, it is pretty reliable: I have to fuss with
this stuff maybe a couple times a year.
Cygwin is worth it. I still don't understand why MS did not just help cygwin
get a better installation/maintenance procedure, and fix the damn fork
problems, instead of going down the UbuntuOnWindows path. But that's another
discussion...
---
Karl Botts, kdbotts@usa.net
--
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