| Summary: | sys-devel/crossdev: provide control over CFLAGSs of toolchain target libraries | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | dE <de.techno> |
| Component: | Current packages | Assignee: | Gentoo Crossdev team <crossdev> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | enhancement | CC: | de.techno, embedded, jstein, slyfox, toolchain |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 461874 | ||
| Bug Blocks: | |||
|
Description
dE
2018-07-01 17:23:56 UTC
(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.
|
