Cygdaemon - planning

Igor Pechtchanski pechtcha@cs.nyu.edu
Wed Jul 2 15:03:00 GMT 2003


On Wed, 2 Jul 2003, Christopher Faylor wrote:

> On Wed, Jul 02, 2003 at 09:34:46AM -0400, Igor Pechtchanski wrote:
> >On Wed, 2 Jul 2003, Christopher Faylor wrote:
> >
> >> On Tue, Jul 01, 2003 at 05:36:49PM -0400, Christopher Faylor wrote:
> >> >On Tue, Jul 01, 2003 at 10:28:35PM +0100, Elfyn McBratney wrote:
> >> >>If it's cool with you, you do the configury hackages.  :-) I'll just
> >> >>submit patches against it as an when needed.
> >> >
> >> >Ok.  I figured that would be your answer.  I've already taken a first
> >> >stab at it.  It isn't working yet, though.
> >>
> >> I've got cygserver building but there are the expected problems with the
> >> fact that some files serve a dual purpose in the DLL and in the
> >> executable, with conditional compilation affecting the client/server
> >> object file personality.
> >>
> >> For now, I've added a USE_CYGSERVER conditional which is turned off by
> >> default.  I've also added a --enable-server option to both the top level
> >> and the cygwin directory.  From the top level this controls whether
> >> stuff in the cygserver directory will be built or not.  From the cygwin
> >> directory it controls whether cygserver support will be built into the
> >> DLL.  This option is off by default.
> >>
> >> My changes to cygwin were not pretty.  I will probably clean them up
> >> later.  I do like being able to build a DLL which does not rely on the
> >> server though, so that part will stay.
> >>
> >> I was wondering if it would make sense for the DLL to autoimport
> >> whatever it needs from cygserver.exe rather than build functionality
> >> into cygwin1.dll?  I think that I would have to release a new version of
> >> binutils which allows this, since autoimporting from a DLL wasn't
> >                                                  ^^^^^^^^^^
> >Did you mean "from a .EXE"?
>
> Duh.  Actually, I meant to say "exporting symbols from a .exe".
>
> >> allowed in binutils into lately, but it seems like a fairly nice way of
> >> localizing all of the cygserver functionality in cygserver itself.  If
> >> cygserver wasn't somewhere in the path, cygwin1.dll wouldn't use it.
> >> Otherwise, it would, when the CYGWIN option was set.
> >
> >How about splitting cygserver into a .exe and a .dll?  Then you could
> >auto-import the functionality from the .dll into cygwin1.dll using the
> >existing binutils functionality...  The .exe could simply be linked
> >against the .dll in that case.
>
> Why split cygserver if it isn't needed?  The functionality is already in
> binutils.  I just haven't released a new version of binutils in a while.
>
> cgf

Chuck was worried about moving some functionality to cygserver that is now
in cygwin1.dll, e.g., ftok().  If cygserver had a .dll, packages such as
cygipc could link against that, and get the functionality.  Unless I
misunderstood Chuck's comment, that is.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton



More information about the Cygwin-developers mailing list