This is the mail archive of the
mailing list for the Cygwin project.
Re: Spurious "You have multiple copies of cygwin1.dll on your syste m."
- From: luke dot kendall at cisra dot canon dot com dot au
- To: cygwin at cygwin dot com
- Date: Fri, 8 Oct 2004 10:53:30 +1000 (EST)
- Subject: Re: Spurious "You have multiple copies of cygwin1.dll on your syste m."
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:
We all make mistakes. :-)
> > > >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? 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
> 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.
I need to have "/" mounted on the local filesystem. 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?
> > 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
> > 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.
> > 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.
The #!/bin/sh, yes, understood.
> > 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
> > 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.
> 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.
> 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. 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).
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'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).
> > 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
It does, a lot, thanks Igor.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html