https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82408
--- Comment #11 from Peter Bohning <peter.bohning at gmx dot com> --- >> And as I recall, "target" defaults to "host". >It does not. Read >https://gcc.gnu.org/install/configure.html As I recall "--target" defaults to [HOST] if you do "./configure --help". I can't double check this since I no longer have a computer. >The linaro toolchain already includes a libstdc++ library so there is no >reason why >you need to recompile GCC/libstdc++ here. I suppose it's probably true that I could just copy the libstdc++ library out of the linaro toolchain into my sysroot... >You still did not describe what kind of cross compiler you want? Do you want >one >which runs on x86_64 (and built on x86_64) that targets aarch64 if so >then just -->target= is needed. If you want one which runs on aarch64 (was >built on x86_64 that >targets aarch64), then --host= and --target= is needed >but you first need a cross that >RUNS on x86_64 to be able to build the target >libraries like libstdc++. As I said twice, I don't want the compiler at all, I just need the libstdc++ library. Target defaulting to host, as "configure --help" did in fact suggest to me, makes sense because the normal behavior would be to compile for the same system one is running at the time. I think perhaps we have misunderstood each other. But my further issue here would be that it seems very unlikely that this configure option would fix the kind of C++ errors I saw in all these various defines. It seems to me that new C++ features have created a bit of a mess. Regardless of course, it will be at least a week before I can try any of this out, but it just seems very very unlikely that setting a configure option that may or may not be what I'm already using, would change these defines which, except for the soft-fp, don't seem like they would be affected by architecture. At the very least, the configure scripts need to check for available language features a little better.
