patch to allow newlib to compile when winsup not present

Robert Collins
Fri Jan 25 14:53:00 GMT 2002

----- Original Message -----
From: "J. Johnston" <>

> No overwhelming reason, however, historically there are already
precedences for
> this.  Newlib already contains system-specific and machine-specific
> files and a system for overriding the common ones.  It supposed to be
> C library.  It is not supposed to be 1/nth of a C library.  Look at
glibc if
> you want an example.  It has multiple directories for system-dependent
> It is a very reasonable design.

I'll accept that you may have system-dependent code that is part of the
C library. If you are implementing user-land threads for instance, then
that is quite clearly a C library, probably system dependent set of
code. However, in this instance, we are implementing 'kernel' threads,
and the typedef will change as that implementation changes, without any
other changes being needed (or appropriate) in newlib.

I'm not suggesting that newlib be a 1/nth C library, just like I presume
you aren't suggesting it become a kernel :}.

> That said, the line between newlib and winsup has not been drawn
> well.

I agree. I recently suggested that winsup have it's binary reorganised
to have more a more explict C library, math libray, and porting layer
approach, which (if accepted :}) will likely help draw the line.
Ideally, the two are orthogonal to each other. But realiy is often more
messy than that.

> A simple solution is to have the header file in question for newlib
> some
> additional ones) have a #error message if Cygwin is being compiled and
> header file
> has not been overridden properly because winsup headers have not been
> in.

Hmm, I wonder if
#ifndef pthread_t
#error pthread_t hasn't be specified for this platform, do you have the
kernel includes available?

will catch a missing typedef correctly? Assuming it won't, the correct
define to check for in this case is _CYGWIN_TYPES_H.


More information about the Newlib mailing list