Mail Archives: cygwin/2001/10/11/13:39:02
Peter Buckley wrote:
> I hope that Bob can read this message to the list,
> if not, Chuck I hope will forward it to him.
>
> My company ships some cygwin stuff, and most recently
> we shipped a product containing some mixed executables and
> cygwin1.dll and cygwinb19.dll. It didn't have any problems
> because the names of the dlls were different.
sort of. The mount table entries are stored under the Cygnus Solutions
key in the registry -- and both DLL's will look there for the
information. So if the two "installations" require different mount
tables, you could see conflict -- except that B19 stored the mount table
undera slightly different subkey than 1.3.3 uses. So, you might *not*
see a conflict. However, this is a non-solution: relying on a quirk in
registry names that just-so-happens to distinguish between B19 and 1.3.3
is not a long term solution.
OTOH, should we really bother to support old dists? Isn't that their
responsibility? (BTW, I assume there ARE distributing the source code
for their cygwin and linked applications, right? Or did they purchase a
support contract from Cygnus/Red Hat -- and if so, then this problem is
a matter for Red Hat to resolve, not this public mailing list)
> I am currently renaming the cygwin1.dll to cw132cp.dll
> and binary-editing (with emacs- don't try this
> at home kids) the executables that depend on cygwin1.dll
> to instead depend on cw132cp.dll. I guess I could recompile
> them, but that would be extra work :-)
This "solution" won't really work. the cygwin dll uses a named memory
area for sharing common data. You are not changing that name -- so your
cw132cp.dll-apps and your normal cygwin1.dll-apps will both access the
same shared memory area. Worse, cygwin1 won't know about cw132cp's
access and changes. This is bad.
You need to recompile cygwin itself -- and ALSO change the builtin
shared memory name. See the archives for info on how to do this.
(You might also think about using a different subkey in the registry for
the mount table, for the same reasons. This would also require changes
to mount.exe in addition to cygwin1.dll)
>
> So far everything is working okay- the executables run
> just fine with the renamed dll. I think that it would be
> very cost-effective for companies to rename the cygwin1.dll
> to a version and company specific name, and then recompile
> the cygwin tools they plan to ship with their product to
> depend on the renamed dll.
Except that as I have mentioned, that won't *REALLY* isolate their
product from a standard cygwin dist.
> We were pretty sure none of our customers were using cygwin,
> but we wanted to minimize calls to tech support about
> "my cygwin is colliding with your cygwin."
>
> Even so, it seems like Altera wasn't very forward thinking
> when they chose their mount points- Isn't it just common
> sense that you wouldn't set / or /usr/bin or important things
> like that?
IMO, the best solution here is for companies to isolate their specific
apps into packages, and install their stuff as a cygwin package into a
"normal" cygwin installation (if a normal cygwin inst doesn't exist,
then install that, too).
It seems that most of what you're seeing is a historical artifact from
the previous "all-in-one-big-package" method of distributing cygwin and
dependent programs (e.g. B19 -- B20.1). Since we now have split things
up into smaller units, it makes sense for companies to follow suit, but
these things take time.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -