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: Spurious "You have multiple copies of cygwin1.dll on your syste m."


On  7 Oct, Igor Pechtchanski wrote:
>  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? ;-)

Apologies, I hadn't understood that the source of the error was me.
 
Unfortunately I think I'm overdue to change over to a new MUA - despite
having "Use From Address" set to: "Luke Kendall" luke.kendall@XXXX...
it doesn't seem to do the right thing.  So I'll just have to suffer 
until I change clients, which seems fair.


> > 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?].

:-)  Yes.

But I don't want to run local install scripts using the local
(incomplete) s=install.  I want to run them on the local system from a
complete network install of Cygwin on, say, a fileserver.

>  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.

I wouldn't dream of attempting the former - running from an incomplete
install would be asking for huge amounts of endless trouble.

> > > 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... :-)

That's what I do, including a post-install after the Cygwin
installation is complete.  This all works fine if kicked off from a DOS
..bat file, but that can't be guaranteed to work because the batch file
can't know that the user actually installed Cygwin in the standard
place, so can't necessarily find the installed bash to run the
post-install script.

That's my motivation for .sh scripting the install rather than .bat
scripting it.  Well, that plus the ten times greater effort to write a
..bat script rather than a .sh script.

> > 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).

Really?  I thought that setup.exe ran a lot of shell scripts as part of
the package post-installs, and these of course expect to find / and /etc
.... and install and modify config files there.

> > 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?

That would seem like bad practice to use explicit paths.  The only
place explicit paths should occur is the #! line, and I can bypass those
by invoking the scripts by calling "sh script-name" for example (rather
than just "script-name" and relying on the #!).  I know what the scripts
are, I wrote them.

> > > > 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...

That would avoid the confusion, even when the message is being read
pedantically.

> > > > 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.

Personally I think that the explicit use of paths to executables is bad
style, so I don't do it, so I know it isn't an issue in this case.

[...]

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

I think you underestimate your own popularity!  If you assume 0.1% of
Windows users install Cygwin, then that represents a huge number.

>  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>.

Hey, that's interesting, thanks!  Even with the missing screen
snapshots, there are some useful tips there.


> > 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.

Sure.  In the old days that was done because Windows used to try to
load the DLL at the base address compiled in, and if there was already
a different DLL occupying that spot, it would find a new free location
and load it there (without checking to see if it itself was alreaDy
loaded).  A friend reported they'd found their database program being
loaded dozens of time and using all free memory, because some other DLL
happened to take the BASE spot it had been compiled for.  I imagine
newer Windows aren't that stupid any more.

Anyway, Christopher didn't seem to think that was the best approach, and
given my lack of time, I'll just try to get this approach working.

> > 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.

No, I'm trying to do the install and post-install stuff using the
complete network install.  Sorry if I expressed myself poorly.

Now to see if I can find where /etc/profile went, and if no joy, try
again with the modified scripts and new knowledge...

Apologies again about the lack of a fullname in my From address.

Thanks again,

luke


--
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/


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