The toolchain copies static libraries from the host system's crossdev toolchain. For e.g. it uses against libstdc++.a. Since objects from these archives are a part of the host system, users must have control over the CFLAGS/CXXFLAGS of these static libraries or they must be copied from the guest system instead from the crossdev's toolchain.
(In reply to dE from comment #0) > The toolchain copies static libraries from the host system's crossdev > toolchain. For e.g. it uses against libstdc++.a. > Since objects from these archives are a part of the host system, users must > have control over the CFLAGS/CXXFLAGS of these static libraries or they must > be copied from the guest system instead from the crossdev's toolchain. I agree Gentoo needs to improve here by handling CFLAGS_${CTARGET} or similar. One clarification: gcc does not copy c++ libraries into target. Those are installed on host only: $ ia64-unknown-linux-gnu-gcc --print-file-name=libstdc++.a /usr/lib/gcc/ia64-unknown-linux-gnu/8.1.0/libstdc++.a Note path does not point to /usr/${CTARGET} (and should not as long as $SYSROOT has no this file either). Today you can cross-buld g++ with cross-emerge into target to control flags. Unfortunately cross-gcc will not automatically use libstdc++.a files from $SYSROOT. I'll try to check why.
Internally gcc calls these variable CFLAGS_FOR_TARGET.
(In reply to Sergei Trofimovich from comment #2) > Internally gcc calls these variable CFLAGS_FOR_TARGET. Is this an env variable? Will settings this make a difference?
*** Bug 659752 has been marked as a duplicate of this bug. ***
Fixed with EAPI 7
I'm not sure anything changed here with EAPI 7, did it?
No, I don't think EAPI 7 has anything to do with this. Assuming GCC lets you set the flags for these, I can't really see how this would work from the Gentoo side. crossdev's cross-emerge does the opposite, setting BUILD_CFLAGS using portageq. For this case to work, the gcc ebuild would need to use portageq to query CFLAGS from /usr/${CTARGET}, but calling portageq from an ebuild is not allowed. Maybe we could make an exception in this particular case, but I wouldn't be happy about it. If you care that much, you could probably do it from an env file. Another workaround is to cross-emerge gcc and then add -L/usr/${CHOST}/usr/lib/gcc/${CHOST}/${GCC_VER} to your flags.