Mail Archives: cygwin-developers/2001/03/28/00:22:24
On Wed, Mar 28, 2001 at 02:55:30PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
>> Sent: Wednesday, March 28, 2001 1:56 PM
>> To: Robert Collins
>> Cc: cygwin-developers AT cygwin DOT com
>> Subject: Re: [jjohnstn AT cygnus DOT com: Re: cygwin/newlib types patchs]
>>
>>
>> On Wed, Mar 28, 2001 at 01:46:15PM +1000, Robert Collins wrote:
>> >> What is cygwin-dependent? Doesn't it make sense to keep
>> everything in
>> >> one place, even if you have to "#ifdef __CYGWIN__"?
>> >
>> >No. The cygwin-classes and internals aren't newlib specific. The
>> >external interfaces are newlib-specific. As an example, if
>> Mumit picks
>> >up his glibc port, the cygwin-classes will stay the same,
>> but the glibc
>> >externals will be needed. Hopefully those external
>> interfaces are posix
>> >standard and there's no difference :]
>>
>> Can you give me an example?
>>
>> cgf
>> (Btw, I've redirected this to cygwin-developers)
>>
>
>Easily. We use
>class pthread
>{
>...
>}
>
>within cygwin. That's accessible from several files, so it's in an
>include. The API uses pthread_t everywhere. When building cygwin we want
>typedef class pthread pthread_t;
>when building userland applications we want
>typedef void * pthread_t;
>
>If a different libc is ever used, the userland defines will (should) be
>the same - they are posix derived. The cygwin "kernel" defines should
>follow cygwin1.dll, not libc.
Ok. I see that linux defines this type of thing in bits/pthreadtypes.h.
I guess our analogy is cygwin/pthreadtypes.h. IIRC, you were going to
modify cygwin/types.h, which is ok.
cgf
- Raw text -