From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6234 invoked by alias); 1 Jul 2016 19:35:32 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 6216 invoked by uid 89); 1 Jul 2016 19:35:31 -0000 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 Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Jul 2016 19:35:21 +0000 Received: (qmail 10379 invoked by uid 13447); 1 Jul 2016 19:35:19 -0000 Received: from unknown (HELO polypore.west.etr-usa.com) ([73.26.17.49]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 1 Jul 2016 19:35:19 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Anecdotal: Rebase and Visual Studio 2015 and /etc From: Warren Young In-Reply-To: <693uFCmXF1392S07.1467203045@web07.cms.usa.net> Date: Fri, 01 Jul 2016 19:35:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3334CBDB-BF42-4CDA-83B5-CCA5B251A746@etr-usa.com> References: <693uFCmXF1392S07.1467203045@web07.cms.usa.net> To: The Cygwin Mailing List X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00016.txt.bz2 On Jun 29, 2016, at 6:24 AM, KARL BOTTS wrote: >=20 > A couple of weeks ago I installed Visual Studio 2015...It is a huge insta= ll -- 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, install= ing 20 gigs should not take hours. (Yes, hours: the recent upgrade to VS 2= 015 SP3 took two hours here.) Maddening. > After that, I had the now semi-familiar problems with cygwin -- "cannot f= ork, > cannot load dlls", that kind of stuff. A VS installation shouldn=E2=80=99t affect the rebase setup of Cygwin. Is this a 32-bit system? If so, and you have lots of Cygwin libraries inst= alled, it can starve rebase of suitable library loading points. That gives= two obvious solutions: 1) Go 64-bit; or 2) Remove stuff you don=E2=80=99t = 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, perha= ps the actual fix was installing fewer Cygwin-based DLLs, thereby giving re= base more freedom to place DLLs. > 1) After you do the full rebase, before you even start anything cygwin, r= eboot > 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=E2=80=99ve 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=E2=80=99re doing it the hard way. After a fresh install, just edit /etc/fstab. The last line in the stock ve= rsion is: none /cygdrive cygdrive binary,posix=3D0,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=E2=80=99ve 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=E2=80=99s doubtless why my symlinks are in order: som= e upgrade along the line fixed them for me. > 3) Once you have a cygwin you like, you can _usually_ copy it to other ho= sts.=20 > Use cygwin cp or tar. rsync -a should also work. > 4) Keep yourself a list of cygwin packages you know you need, You don=E2=80=99t 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=E2=80=99t need many packages, you can prune the long list produc= ed by that $() construct way down, so that you install only the =E2=80=9Cro= ot=E2=80=9D packages that cause all the others to be installed as dependenc= ies. > I have had trouble > with the "setup -P", sometimes, but I think you could get that to work. I=E2=80=99ve 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. I= f it doesn=E2=80=99t and you get no postinstall script errors, you can safe= ly 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 do= esn=E2=80=99t get its hooks into the system deeply enough to cause such tro= uble, > And, it moves > DLLs around, even installs more, on the way back up. =E2=80=9CIt=E2=80=9D being Windows, or Cygwin? If the former, new Windows DLLs shouldn=E2=80=99t interfere with Cygwin DLL= s, unless by some wild coincidence there is an overlap in memory load space= s. And again, that=E2=80=99s solved by either using 64-bit Windows and 64-= bit Cygwin or not installing so much stuff that conflicts are near-inevitab= le. If the latter, Cygwin doesn=E2=80=99t install new things on bootup. Once s= etup.exe exits, your Cygwin installation should be stable until you fire se= tup.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. Ballm= er and his predecessors had no interest in helping Windows work with non-Wi= ndows platforms. Nadella=E2=80=99s coming along now and bailing like mad, = trying to keep the ship afloat despite their two major cash cows (Office an= d 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 und= ocumented. 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