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

On Thu, 7 Oct 2004, Igor Pechtchanski wrote:


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


...Without speaking to any of the other issues of this thread, I can
provide commentary about the above comments; In short, it's not very
difficult to configure a shared installation with as much local deviation
as you wish. We do it here with a great many software packages that were
"never intended" to be managed this way. Here's the go:

Start with an intact, proven working installation directory tree that's on
a served network drive (by whatever means). Then, on each "installation
client" provide a complete directory tree that matches the structure of
the networked tree in every particular, at least in so far as local
modifications are desired. Then, each directory on the client nodes are
populated with links back to the network counterpart. When particular
sections of the tree don't need any local variant, a link can be provided
at the directory level to present entire branches of the directory tree
from the networked installation.

Of course, this has nothing to do with Cygwin, and, now that I think of
it, I'm not sure I've ever done this with a Cygwin-served
(Windows-served) directory tree, but I can't think of any reason why this
wouldn't work just fine in an all-Windows environment.

Hope this helps,

P.S. Igor, regarding execv(), I had indeed 'malloc'ed just enough memory
for nargv and the extra null was in fact in non-malloced memory! Arg! What
surprised me was that the write to that memory space was permitted and it
failed sometime later when that memory location was needed/used for
something else! (wtf? -frown- )  Tnx, RT P.P.S. My Windows XP Pro
_doesn't_ have ping or dig/nslookup?! -frown-  Tnx again, RT

Richard Troy, Chief Scientist
Science Tools Corporation, 510-567-9957,

Unsubscribe info:
Problem reports:

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