Adding a new target to newlib

["KJK::Hyperion" <noog at libero dot it>]

Hi all. I'm the main developer of POSIX+, a POSIX compatibility layer for
Windows NT and ReactOS (<http://www.reactos.com/>). Under suggestions from
other team members, I've decided to evaluate newlib to provide POSIX+ the
C runtime. Before investing time into the adaption, I need a general
understanding of a few concepts. I'll bother you this one time, then rely
on the documentation. Feel free to RTFM the trivial questions. Let's see:
 - do I need a POSIX-like shell to build newlib? because I'd have a nasty
   chicken-egg problem then: I can't have a POSIX shell until POSIX+ is
   compiled, I can't compile POSIX+ until newlib is compiled, and I can't
   compile newlib without a shell. Even a future self-hosted version is
   out of question, because the team has gone to great lengths to minimize
   the requirements to build ReactOS. A possible advantage is that POSIX+
   will (likely) have only one public, official version, and the only
   variants will be architecture-specific builds: does this help? will
   some old-fashioned makefiles do?
 - is newlib thread-safe by default, or only for multithread-aware
   programs? (e.g. *_r variants of standard functions) I'm trying to
   follow the Single Unix Specification, and it clearly states that all
   functions are meant to be reentrant and thread-safe, except when
   otherwise noted
 - POSIX+ defers simple runtime functions (e.g. memcpy, memcmp, strcpy,
   etc.) to a system-wide runtime library (NTDLL.DLL). Is it dangerous to
   mix the two runtimes? does it lead to inconsistent behavior? e.g. some
   of these functions are interdependent in newlib?
 - is it possible to compile newlib into a Windows DLL, or does it depend
   on POSIX linking semantics? e.g. symbols need not be qualified with a
   DLL name?
 - to what extent is newlib extensible? Specifically:
    - can the per-process and per-thread data be customized/extended?
    - does asynchronous I/O depend on POSIX threads, and can it be
      implemented otherwise without breaking something else?
    - NT has a very good heap manager, can it be used in place of the
      internal one used (I presume) by newlib?
    - to the NT Rtl, heaps are just another kind of data structures, so a
      process can have as many heaps as it sees fit (Microsoft suggests,
      for example, the use of throwaway per-thread heaps for aggressively
      multi-threaded programs, like ISAPIs, to minimize the context
      switches under heavy load). Does some other target have similar
      semantics, whose API I can "recycle"? if not, are there guidelines
      for new identifiers/prototypes?

Finally, a "political" question: what about licensing? POSIX+ must be
under the GPL, and I guess that the various newlib licenses don't conflict
with it. But what about headers? to allow unlimited commercial use of
ReactOS system libraries, all of our public headers and DEF files (source
code for import libraries) are under no license, we don't even claim
copyright. What about newlib's?

Thanks in advance