compiling the cygwin1.dll [was Re: Multiple cygwin installs: I have to do it, but how?]

[Peter Buckley]

I have searched the archives with google, and 
the faq and users' guide- the search terms I 
used were:

compile cygwin1.dll
recompile cygwin1.dll

The first set yielded MANY results, but after 125 
results of 
"compile <some-other-thing> 
<some-error-relating-to-the> cygwin1.dll" 
I think I need different search terms. 

Should I be following the users' guide entry 
about "Building DLLs" to build the cygwin1.dll?
Or should I do a "configure" and "make", with 
some fancy options in the cygwin-1.3.2-2 source 
dir?

Should I be looking at changing the source code 
to change the name and location of the 
"named memory area"? What is this officially called 
in the source? 

Or is there an option to gcc or the dlltool that 
will allow me to use a different name for my compiled 
cygwin1.dll and a different name and location of the 
"named memory area" of my compiled cygwin1.dll?

I would love some pointers on better search terms, 
both for the mailing archives and for the source 
if that is what I need to change.

TIA,
Peter

Charles Wilson wrote:
> 
> 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

-- 
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now?  [OK]

--

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