This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Adding a new target to newlib
- From: "KJK::Hyperion" <noog at libero dot it>
- To: newlib at sources dot redhat dot com
- Date: Tue, 18 Jun 2002 00:39:30 +0200
- Subject: Adding a new target to newlib
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