Add xdr support
Sat Feb 13 21:01:00 GMT 2010
On Sat, Feb 13, 2010 at 10:20:20AM -0500, Charles Wilson wrote:
>Corinna Vinschen wrote:
>>On Feb 13 01:43, Charles Wilson wrote:
>>>The attached patch(es) add XDR support to cygwin
I didn't get Corinna's response in email and it isn't in the archive.
I assume that was unintentional?
>>>The cygwin components are basically just adding the new exports, and
>>>providing a callback function for the error reporting framework in the
>>>xdr implementation, that uses (in effect) debug_printf().
>>Is it really necessary to do that in init.cc? Shouldn't it be
>>sufficient to set it in dll_crt0_1?
>Yes, I just wasn't sure /where/ it should be done. It needs to be
>early, before anything would try to use XDR. If you think dll_crt0_1
>is more appropriate, that's fine with me.
The benefit of putting this in init.cc, or something called from
init.cc, is that it will work better if cygwin is dynamically loaded. I
don't really care too much if that case works though. If that was the
intent then the function should be called from dll_crt0_0 rather than
However, I probably agree with Corinna that it should go in dll_crt0_1.
>Alternatively, the newlib code could be changed so that the error
>reports go /nowhere/ until a caller sets up a reporting mechanism.
>Then, I suppose, it's much less important how early cygwin does that.
>Right now, the newlib code defaults to using stderr.
>I'd have to make the 'set up error reporting' function public, in that
>case. (Right now, it is sorta hidden: that's why cygxdr.h has to declare
>the setter function itself).
I have to wonder if these really belong in newlib. I have an anti-newlib
bias (not to be confused with the ficitious other biases that I've been
accused of) so maybe it's that talking but it seems like you've gone to
some effort to ensure that things work for the non-cygwin case. Would
it have been easier if you just imported everything into Cygwin?
Also, follow-up question: Should this go into a different library
entirely? Is it time to think about not just making cygwin1.dll the
monolithic one-stop-for-all-of-your-posix-api shared library?
More information about the Cygwin-patches