This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygdaemon - planning


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


Well, I dunno about this. It makes sense in theory -- but what if I have a non-cygserver application that depends on symbols that are now available only from cygserver.exe?

I'm thinking specifically of ipc-daemon2, libcygipc, and ftok(). (It may be that ftok() is the only such symbol that may be affected by this plan, I don't know).

In any event, whatever you do, please make sure that ftok(), at least, stays in cygwin1.dll and doesn't get "moved" to cygserver.exe.

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]