X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=e6oyEx6uzY6EJhZdr7RppcH0+nXW
	3CsJNkK+korSfQYBVGW9ohqn2Xxhfcr/3ycn8y2gLcL36uVSDjy9IlSc/8ekPcO+
	NCwpH4mLL3zrTDae1ILGYQtZrc6zMuLV4W5AJFnjBWWmPmBXE4q3cIv2psNbwjpM
	0eGvxKEfnGxbFXY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=xdkoj5jyq3ISnoEg6bZ3uOLGEm8=; b=Bs
	GoNSKfiRfncwCy55pQYuB+88v6VQmcwvdgN2qhYarK4BI23q8e5f6xxMRBpxT+Ay
	3z+hp5+0S3hAQho7/AntDEWISMrBY48xw1t8BBYkb8KTCYDzmU0OAmSfGSoqh2bo
	J5uQVZ6j7Pki/ou2jBDpuR2/HeLsBa4n8R2Ip/hzM=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	=?ISO-8859-1?Q?No, score=-0.0 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=thereby, you=e2, kdbottsusanet, D*usa.net?=
X-HELO:	etr-usa.com
Mime-Version:	1.0 (Mac OS X Mail 9.3 \(3124\))
Subject:	Re: Anecdotal: Rebase and Visual Studio 2015 and /etc
From:	Warren Young <wyml AT etr-usa DOT com>
In-Reply-To:	<693uFCmXF1392S07.1467203045@web07.cms.usa.net>
Date:	Fri, 1 Jul 2016 13:35:17 -0600
Message-Id:	<3334CBDB-BF42-4CDA-83B5-CCA5B251A746@etr-usa.com>
References:	<693uFCmXF1392S07 DOT 1467203045 AT web07 DOT cms DOT usa DOT net>
To:	The Cygwin Mailing List <cygwin AT cygwin DOT com>
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u61JZhDG028641

On Jun 29, 2016, at 6:24 AM, KARL BOTTS <kdbotts AT usa DOT 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

- Raw text -