This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
RE: [jjohnstn@cygnus.com: Re: cygwin/newlib types patchs]
- To: <cygwin-developers at cygwin dot com>
- Subject: RE: [jjohnstn@cygnus.com: Re: cygwin/newlib types patchs]
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Wed, 28 Mar 2001 14:55:30 +1000
- Thread-Index: AcC3Ogw0d/VXt6QtRhaEvhGdAlSVVQAAAg2w
- Thread-Topic: [jjohnstn@cygnus.com: Re: cygwin/newlib types patchs]
> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> Sent: Wednesday, March 28, 2001 1:56 PM
> To: Robert Collins
> Cc: cygwin-developers@cygwin.com
> Subject: Re: [jjohnstn@cygnus.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.
Rob