This is the mail archive of the cygwin-patches 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: Add xdr support


Corinna Vinschen wrote:
> On Feb 13 16:01, Christopher Faylor wrote:
>> 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
>>>> Cool.
>> I didn't get Corinna's response in email and it isn't in the archive.
>> I assume that was unintentional?
> 
> Yes, sorry about that.  Apparently I hit the r button accidentally,
> rather than the l button(*).
> 
>> 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?
> 
> Ideally libcygwin.a provides all the API which is expected in libc
> on other targets.
> 
> I don't know if that works, but it would be really cool if a single
> DLL import lib like libcygwin.a could export symbols from different
> DLLs.  That way we could create a cygxdr1.dll which contains the XDR
> functions, but which could be linked against by just the default linking
> against libcygwin.a.

Oh, it's certainly possible:

dlltool --identify /usr/lib/w32api/libvfw32.a
AVIFIL32.DLL
AVICAP32.DLL
MSVFW32.DLL

but I think it would be very hard to do that, IF the core implementation
code "lived" in newlib, rather than cygwin proper. So, this would almost
require that the core impl code be moved into winsup/cygwin -- and even
then, it requires additional complications for the build process and
mkimportlib. (Also, I'd have to export the 'set up the error reporting'
function, which I currently don't do).

I'm somewhat unenthusiastic about that.

> However, that would be link stage magic which has nothing to do with
> availability in source.  I have no problems with it being in newlib
> (though I doubt I had the idea in the first place).  This way other
> targets would get this OS-agnostic functionality as well.

Yes, that is my current thinking.

--
Chuck


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