https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82408
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Peter Bohning from comment #11) > >> 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. Yes it might but you are then building a compiler which will run on aarch64 and targets aarch64, not a cross compiler which runs on the machine you are building on and targeting aarch64. But since you longer have access to a computer I cannot help you figure out what you did wrong; thus closing this bug as invalid is the correct thing. > > >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. You can't have just libstdc++ without the full GCC. That is my point. > > 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. Well ok, maybe configure should check to make sure you are using the same version of the cross compiler as the library is created with. But this check would just slow down configure step and for most people it would be a nop as the build==host for most builds of gcc. Again the main reason why the target libraries that are included in GCC require a compiler which runs on the same machine as the target library are written for that version of GCC and only that version of GCC (though the library is binary backwards compatible but nobody can ever claim a new target library can be built with a compiler which is older).
