Re: Spurious "You have multiple copies of cygwin1.dll on your system."

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Fri, 8 Oct 2004, luke.kendall wrote:

> On  7 Oct, Igor Pechtchanski wrote:
> >  On Thu, 7 Oct 2004, luke.kendall wrote:
> >
> > > On  7 Oct, Christopher Faylor wrote:
> > > >  On Thu, Oct 07, 2004 at 02:49:29PM +1000, luke.kendall@XXXXX.XXXXX.XXX.XX wrote:
> >
> >  Erghm...
>
> We all make mistakes.  :-)

Well, "erghm" to you, then...  Could you please add a fullname to your
e-mail address, so that these mistakes happen less often? ;-)

> > > > >After installing Cygwin by using a shell script running by executing
> > > > >bash from a network-installed Cygwin, the script fails when it tries to
> > > > >run a post-install script.  The error reported is:
> > > > >
> > > > >    bash-2.05b$ post-install.sh -which latest -fresh
> > > > >    c:\cygwin\bin\bash.exe (3208): *** cygheap version mismatch detected - 0x616D0000/0x61780000.
> > > > >    You have multiple copies of cygwin1.dll on your system.
> > > > >    Search for cygwin1.dll using the Windows Start->Find/Search facility
> > > > >    and delete all but the most recent version.  The most recent version *should*
> > > > >    reside in x:\cygwin\bin, where 'x' is the drive on which you have
> > > > >    installed the cygwin distribution.
> > > > >
> > > > >A search showed that there really is only c:\cygwin\bin\cygwin1.dll -
> > > > >the message is wrong.
> > > > >
> > > > >I'd say the sanity-check is detecting cygwin1.dll associated with the
> > > > >bash that's running from the network-mounted drive.
> > > >
> > > > You wouldn't say that if you knew what "cygheap" was.  This is an
> > > > indication that a child executable is detecting that its cygheap is
> > > > not at the same location as the parent.  Since the cygheap lives at
> > > > the end of the cygwin DLL it's hard to see how this could be anything
> > > > other than two different versions of cygwin being invoked.
> >  >
> > > Okay, and in fact there are two (possibly different) versions of
> > > cygwin1.dll available to be loaded into memory.  I don't know why
> > > Cygwin attempted to load the freshly-installed cygwin1.dll, though.
> > > It wasn't on the PATH of the network-loaded shell script.
> >
> > As Dave said, Windows loads the DLLs from the app directory before going
> > through the PATH.  I'd bet there's a /bin/sh (or something of the sort)
> > call in the post-install script, which, after you've changed the mounts,
> > points to c:/bin (which is the newly-installed Cygwin).
>
> Ah, I'll bet you're right.  I can invoke them directly via sh/bash.
>
> >  Basically, it's not enough to share the network directory -- you also have
> >  to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the
> >  network copy of Cygwin to work properly.  So, your mount changing idea may
> >  not be so off the mark after all, but in the other direction (i.e., switch
> >  "/" back to the network drive)...
>
> Erm, yes.  But to just run shell scripts and things like grep, sed,
> etc., do you think I might get away without them?

Nope.  Read on.

> Because, as you say:
>
> > Unfortunately, anything written to those directories will then also go
> > back to the network drive, which isn't what you want.  Sort of a
> > Catch-22 here...
>
> Yes.  I'm about to start investigating what's happened to /etc/profile
> and a whole bunch of other files in /etc that aren't there following my
> 2nd trial of the shell-driven install, with /tmp mounted (but not /).
> It may be as simple as doing a mount c:/cygwin / before starting
> setup.exe.

That's if you want to run local install scripts using the local install
(which may not be fully installed yet -- catch-22 again) [meta-note: have
I used the word "install" often enough?].  As I see it, there are two
issues: the one I just mentioned (incomplete install), and triggering
Cygwin processes using the local cygwin1.dll from a shell using the remote
cygwin1.dll.  The latter I already mentioned a solution for; risking the
former is a judgement call.

> > One question is: do you have to use the actual POSIX paths in your
> > install script?  If you can have a uniquely-named mount (say,
> > "/local-install"), and use that in your install script (e.g.,
> > "/local-install/bin", etc), you should be able to circumvent this
> > issue.  Since you're the administrator, you can just decree that your
> > users shan't have a mount named "/local-install" on their existing
> > Cygwin installations).
>
> I don't quite understand, though I can see roughly the value in using
> unique mount points to separate the network Cygwin from the installed
> (or about-to-be-upgraded) Cygwin.

The idea is that your install script will treat the local Cygwin
installation as just another data directory tree.  You could use templates
to generate config files, etc -- if your installations are standardized,
you may even get away with it... :-)

> I need to have "/" mounted on the local filesystem.

Note: eventually.  You can re-mount everything locally after you've
finished running your install scripts (as a last step of the install
script, in fact).

> So if I make a /local-install directory under /, and mount the network
> Cygwin filesystem there, and set PATH to have that first, and always run
> #!/bin/sh scripts by explicit "sh the-script", then it should be okay?

Nope.  What if those scripts invoke /bin/grep?  Or /usr/bin/perl?

> > > To be pedantic, the warning is wrong because it says you have multiple
> > > copies of cygwin1.dll on your system.  There aren't, and indeed a
> > > Search for cygwin1.dll using the Windows Start->Find/Search facility
> > > confirms that there is only a single cygwin1.dll, freshly installed.
> >
> > Well, network drives are technically drives on your system too.  If you
> > can't find multiple copies of cygwin1.dll on your local drives, but an
> > extra copy exists on a network drive, the error is correct.
>
> :-)  I think you're stretching things a little there.  :-)  Most people
> wouldn't consider network filesystems to be "on" their system.  But
> since I'm being very pedantic anyway, I shouldn't argue any more about
> that.  :-)

Well, we could change the "on" in the above message to "accessible from"
with little loss of generality or addition of content...

> > > Try this: from a machine on your network, with Cygwin installed, share
> > > the c:/cygwin directory (i.e. the path where you installed Cygwin).
> > >
> > > On another PC, start a DOS window.  set PATH=this network Cygwin path
> > > Type bash.  You get a bash prompt.
> > >
> > > Now you have a situation where cygwin1.dll is loaded in memory from
> > > across the network.  And if you have Cygwin installed on the local
> > > machine, you don't get error messages about multiple Cygwin versions
> > > installed on your PC.  You can run all the Cygwin commands.
> >
> >  ...Until you use an absolute path to invoke a command (e.g., /bin/sh) with
> >  mounts pointing to the local installation...
>
> Thanks for that, I reckon it will let me solve my problem.

That was actually a caveat, not a solution.  If you have an invocation
like /bin/sed (just to make it interesting) in one of your scripts, and
you run that script from "sh" using the remote cygwin1.dll, and /bin
points to a local disk -- BOOM.

> > > So even knowing that the error message is imprecise and misleading in
> > > this situation, and that it probably means that Cygwin tried to load up
> > > cygwin1.dll from a different path to a copy that's already loaded, and
> > > that it's incompatible with the one that's already loaded, I don't know
> > > why Cygwin is trying to load this other DLL.
> >
> > Mounts.
>
> The #!/bin/sh, yes, understood.

And /bin/grep, /bin/awk, /bin/rm, you get the picture.

> > > I suspect the error message should be "Attempting to load an
> > > inconsistent version of cygwin1.dll".
> >
> > How's "version mismatch" different from "inconsistent version"?
>
> It's not.  Sorry, I should have tried to make a minimal change to the
> error message.
>
> > > I freely confess I'm doing something unusual.  Maybe I'm the first
> > > person on the planet to attempt to automate Cygwin installation via a
> > > shell script from an already existing and stable copy of Cygwin
> > > installed elsewhere on the network?
> >
> >  Likely you are.  There just aren't that many people using Cygwin,
>
> ?!  I would have thought tens of thousands minimum, but you'd know
> better than me.

There were some numbers posted, but low thousands would be my estimate.
Compared to millions using Linux...

> > and even fewer that are administering it (and even fewer that are
> > doing it remotely, I guess).
>
> True.  I like automation.  Even traditional Windows administrators can
> gradually be converted over to the Unix philosophy, I've discovered, as
> you show them how much you can achieve with the traditional Unix tools.

BTW (OT), there was a web page I found once, called "Command-line NT: It
does exist!".  Unfortunately, the original is gone to the happy place
where all old internet articles go, but you can still read it through the
Internet Archive: <http://web.archive.org/web/20030621125700/http://www.linuxworld.com/linuxworld/lw-1999-04/lw-04-thereandback.html>.

> > I'm about to tread onto the grey area here, and would like to disclaim
> > that this is in no way approved by the Cygwin team:
> >
> > *If* you know what you're doing, and *if* you're careful, and *if* you
> > have a real need (which I suspect you do in this case), you *can* run
> > two mismatched versions of Cygwin occasionally.  Take a look at the
> > way the Cygwin test suite is run -- it runs with a newly-built DLL all
> > the time. Note that you'll need to have a unique cygheap id for the
> > network copy of Cygwin that is guaranteed to differ from any installed
> > Cygwin's id.  The easiest way to do that is have your network Cygwin
> > built with debugging enabled.  As long as you don't try doing anything
> > exotic (e.g., start network services using both copies of
> > cygwin1.dll), it should work.
>
> So far I've never built a Cygwin from source, and it may require more
> time than I scrape together away from my real work.

It's not that hard, BTW.  The instructions are pretty comprehensive, and
it should build OOTB.  If you're worried about the size of the resulting
DLL, feel free to strip it afterwards -- you'll only need the debugging
bit for the cygheap id.

> If I've understood, you're saying that you link the cygwin1.dll with a
> different BASE address?  But from W2K on, Windows allows the loading of
> different versions of the same DLL, provided you use full pathnames (and
> the paths are different, obviously).

Nope, you embed a different cygheap id (there's that dirty word again) in
the DLL, so that when it creates a shared memory area, it doesn't tread on
that of the other DLLs.

> But for my purpose, even if Cygwin did let you do that without
> recompiling, I'm now hopeful that it'll be possible to run a network
> Cygwin on another machine, if I don't have any installed Cygwin
> processes running on that other machine.

I must've misunderstood what you were trying to do.  I thought you were
trying to install Cygwin via a remote script, and then run the postinstall
procedure using the local installation...  If so, you *will* have Cygwin
processes running concurrently that use different versions of cygwin1.dll.

> I'll see how I go.
>
> > Combined with the idea for a uniquely-named mount for the local Cygwin
> > install (i.e.: save local mounts; mount network Cygwin properly; mount
> > local "/" on "/local-install" [with local "/usr/bin" and "/usr/lib"
> > mounted accordingly]; run script; restore local mounts), the above
> > should give you a working installation procedure (text/binary issues
> > aside).
>
> Hmm.
>
> > > Anyway, I'll keep battering away at the attempt, and see if I can find
> > > something on cygheap so I understand more about what's going on.
> > >
> > > Thanks,
> > > luke
> >
> >  HTH,
> >  	Igor
>
> It does, a lot, thanks Igor.
>
> luke

Good luck.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/