This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |