Cygdaemon - planning
Elfyn McBratney
elfyn@cygwin.com
Wed Jul 2 15:07:00 GMT 2003
On Wed, 2 Jul 2003, Igor Pechtchanski wrote:
> 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.
Regarding ftok(), IMO that should stay where it is. It's expected to be in the C
library, and there's no need to have it in cygserver now.
Elfyn
--
More information about the Cygwin-developers
mailing list