RE: another proposed crosstool project

["Dave Korn" <dave dot korn at artimi dot com>]

On 06 May 2007 18:17, Jonathan S. Shapiro wrote:

> Things get much more complicated if you also need to cross-build g++.

  Yep.  C++ is a much more complicated language than C.  It certainly requires
a fairly full standard C library implementation.

> 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++.

  Right.  Libiberty is the GNU standard portability-support library.

> 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.

  Yes, you need to port libiberty to your target.  This means your target
needs auto* support.

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

  If there aren't autoconf tests that detect the lack of this function and
disable whatever relies on it, you'll have to supply a dummy wrapper for your
target.  Just one that always returns a fixed time of the epoch would suffice;
you'd simply have to remember not to use any libstdc++ functions that relied
on times.

  BTW, have you investigated whether the --disable-hosted-libstdcxx option
might help?
 
>   Coyotos doesn't have anything remotely like a signal. A depressing
>   number of cross tools and libraries assume that this is available.

  Well, I don't know what you're referring to here, that's a very vague
description of the problem.  Again, this problem is not insoluble, by
providing wrappers and avoiding invoking the unimplemented functionality in
your applications; see the way newlib provides libnosys stubs.
 
> 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.

  Surely they can never have been so portable as to build on a system that has
no support in the config* and auto* framework?

> 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.

  It may be that something is being assumed that should more usefully be
tested, but AFAIR, glibc has /never/ been a simple thing to port to a tiny
embedded board, it's always been aimed at desktop workstation-sized machines.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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