Re: Cygdaemon - planning

[Christopher Faylor <cgf at redhat dot com>]

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