On Jun 29, 2016, at 6:24 AM, KARL BOTTS <kdbo...@usa.net> wrote:
>
> A couple of weeks ago I installed Visual Studio 2015...It is a huge install
> -- 20GB disk space, more than an hour, a couple of reboots.
In a world where main storage is measured in 100s of MB per second, installing
20 gigs should not take hours. (Yes, hours: the recent upgrade to VS 2015 SP3
took two hours here.)
Maddening.
> After that, I had the now semi-familiar problems with cygwin -- "cannot fork,
> cannot load dlls", that kind of stuff.
A VS installation shouldn’t affect the rebase setup of Cygwin.
Is this a 32-bit system? If so, and you have lots of Cygwin libraries
installed, it can starve rebase of suitable library loading points. That gives
two obvious solutions: 1) Go 64-bit; or 2) Remove stuff you don’t actually need.
> Eventually, I reinstalled a fresh cygwin
Did you install all the same things, or a minimal install, which you built on
top of, installing only things you need right now? If the latter, perhaps the
actual fix was installing fewer Cygwin-based DLLs, thereby giving rebase more
freedom to place DLLs.
> 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.
I’ve never had to resort to such voodoo to keep Cygwin going. The standard
schedule of reboots due to Patch Tuesday has been sufficient.
> 2) I always have cygdrive-prefix set to /
Me, too.
> 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.
You’re doing it the hard way.
After a fresh install, just edit /etc/fstab. The last line in the stock
version is:
none /cygdrive cygdrive binary,posix=0,user 0 0
Just change the second field to / and restart Cygwin.
> Then, you should
> patch up the symlinks in /etc/{hosts,services,couple-more}
I’ve never manually done that, primarily because I rarely use such files via
Cygwin.
You can force Cygwin to fix such things up for you by reinstalling the
base-files package. That’s doubtless why my symlinks are in order: some
upgrade along the line fixed them for me.
> 3) Once you have a cygwin you like, you can _usually_ copy it to other hosts.
> Use cygwin cp or tar.
rsync -a should also work.
> 4) Keep yourself a list of cygwin packages you know you need,
You don’t need to; Cygwin itself remembers what you have installed.
To clone an existing install using setup.exe:
$ /path/to/setup-x86_64 -R 'c:\cygwin-clone' -q -L \
-P $(tail -n+2 installed.db | cut -f1 -d' ' | tr '\n' ,)
The installed.db file is copied from the machine whose Cygwin installation you
want to clone. It lives in /etc/setup.
If you don’t need many packages, you can prune the long list produced by that
$() construct way down, so that you install only the “root” packages that cause
all the others to be installed as dependencies.
> I have had trouble
> with the "setup -P", sometimes, but I think you could get that to work.
I’ve just tested the above command here to create a local clone. I encountered
no trouble once I had the command debugged.
> 5) Again, reboot Windows between any steps.
If that is needed after setup.exe exits, setup.exe itself will tell you. If it
doesn’t and you get no postinstall script errors, you can safely assume that
your new Cygwin installation is ready to use.
> you want to know that it _will_ reboot, anyhow.
Cygwin should never cause a Windows box to become unbootable. It simply
doesn’t get its hooks into the system deeply enough to cause such trouble,
> And, it moves
> DLLs around, even installs more, on the way back up.
“It” being Windows, or Cygwin?
If the former, new Windows DLLs shouldn’t interfere with Cygwin DLLs, unless by
some wild coincidence there is an overlap in memory load spaces. And again,
that’s solved by either using 64-bit Windows and 64-bit Cygwin or not
installing so much stuff that conflicts are near-inevitable.
If the latter, Cygwin doesn’t install new things on bootup. Once setup.exe
exits, your Cygwin installation should be stable until you fire setup.exe up
again.
> 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.
Because Satya Nadella has been in charge for only about two years now. The
time to help Cygwin with the fork() problem was about 15 years ago. Ballmer
and his predecessors had no interest in helping Windows work with non-Windows
platforms. Nadella’s coming along now and bailing like mad, trying to keep the
ship afloat despite their two major cash cows (Office and Windows) shrinking
fast in profitability. Things like WSL are just side effects of that mad
activity.
The new WSL is also architecturally more in line with the way the NT kernel was
designed. From that perspective, Cygwin is something of a hack.
Not that Cygwin had any choice; the NT subsystem interface is basically
undocumented. Plus, implementing Cygwin that way would have prevented it from
supporting Windows 95 thru ME, and presents other interop problems besides.
--
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
