Mail Archives: cygwin/2001/07/26/19:49:57
On 26 Jul 2001 08:36:37 -0700, Dario Alcocer wrote:
> >>>>> "Chuck" == Charles Wilson <cwilson AT ece DOT gatech DOT edu> writes:
>
> Chuck> **IF** you're going to pursue this, The Right Way(tm) is to
> Chuck> build a special cygwin1.dll AND import lib environment,
> Chuck> where the "shared memory region name" is different -- and
> Chuck> perhaps the dll name itself, as well. Also, it should use
> Chuck> a different registry key for mounts and such,
> Chuck> probably. (Check the cygwin archives wrt. error_start and
> Chuck> gdb for some info on how to do the "shared memory region
> Chuck> name" thing). Then, build your special ash and rpm and db
> Chuck> and utils within that environment (you may need to also
> Chuck> build gcc?)
Mounts shouldn't be changed - it needs to install into the cygwin
mounted directories.
> Chuck> The difficulty here is you've got to maintain TWO separate
> Chuck> binaries for your core utilities -- one set of (cygwin
> Chuck> itself, ash, rpm, db, etc) for the "real" system and one
> Chuck> set for the "mini" environment.
The mini environment shouldn't need different binaries, just a copy in
the toolkit, launched with a custom PATH.
> I think this would be the major sticking point; having a parallel
> set of Cygwin binaries would be problematic, both for maintenance and
> support.
I don't think changing the .dll name would be needed - it would be outof
the system path, and in the same dir as all the binaries for the
toolkit. Changing the shared memory area is needed IMO, but that can be
done by a simple #ifdef in one location in the cygwin dll source. ie #if
_CYGWIN_INSTALLER_DLL_
#else
#endif
Rob
--
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 -