RE: another proposed crosstool project

["Jonathan S. Shapiro" <shap at eros-os dot com>]

On Sun, 2007-05-06 at 17:43 +0100, Dave Korn wrote:

>   To build the cross-compiler, you need the standard headers and libs from the
> target: that is, the headers that define the C standard library functions and
> the libraries that implement them, along with the CRT startup .o files.  The
> compiler, as you say, cannot know how to implement syscalls; it just emits a
> function call to a function in the standard C library, and at runtime this
> function is linked in and does the necessary syscall or whatever.

I am sorry, but you are quite mistaken.

What you say is true if we are only concerned with building gcc. In this
case, there is a very short list of headers that are required by newlib.
These are even reasonably well documented.

Things get much more complicated if you also need to cross-build g++.
The g++ compiler itself isn't difficult, but any *useful*
cross-environment supporting C++ must include libstdc++. Even libstdc++
isn't that bad (there are a few UNIX dependencies, but not that many).
Unfortunately, the GNU tool chain requires a libiberty to cross-build
libstdc++.

Now libiberty, unfortunately, has overwhelming UNIX dependencies. The
list of headers required for this, and the actual statement of what
libiberty really requires, aren't documented anywhere that I have been
able to find.

Two concrete examples:

  Coyotos has no direct substitute for the time() family of functions.
  Some of the classes in libstdc++ appear to require this.

  Coyotos doesn't have anything remotely like a signal. A depressing
  number of cross tools and libraries assume that this is available.

This is *very* frustrating. Both glibc and libstdc++ *used* to be
portable to non-UNIX systems. Somewhere along the way, that ceased to be
true. Today, glibc depends so deeply on the POSIX API that it would be
easier to build a new C library from scratch than to "fix" the issues in
glibc.


shap


--
For unsubscribe information see http://sourceware.org/lists.html#faq