This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

On Jun 29, 2016, at 6:24 AM, KARL BOTTS <> 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.)


> 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]