Summary: | flag-o-matic.eclass: `CHOST=${CTARGET} strip-unsupported-flags` doesn't strip flags | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Eclasses | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl, henrique.ribeiro.dias, sven.koehler, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 461874 | ||
Attachments: |
cross-spu-elf-info.log
cross-spu-elf-newlib.log.xz newlib-config.logs.tar.xz |
Description
Dennis Schridde
2012-12-22 18:37:47 UTC
Created attachment 333060 [details]
cross-spu-elf-info.log
Created attachment 333062 [details]
cross-spu-elf-newlib.log.xz
Created attachment 333064 [details]
newlib-config.logs.tar.xz
P.S: I ran # crossdev -oO /var/cache/portage/local spu-elf Same thing using crossdev-20120913 from ambro-cross overlay. *** Bug 449046 has been marked as a duplicate of this bug. *** I don't understand the subject line, but is it intended, that the CFLAGS for the cross-compiles code derived from the ordinary CFLAGS variable just by stripping some of the flags? Is there a way to override the CFLAGS for cross-compiled code explicitly? I.e. use -Os for cross-compiled code (libstdc++, libgcc, etc.) and -O2 for code that runs on the host (e.g. gcc compiler binary)? (In reply to comment #7) > I don't understand the subject line, but is it intended, that the CFLAGS for > the cross-compiles code derived from the ordinary CFLAGS variable just by > stripping some of the flags? That is what I wondered, too. I would expect portage to use the CFLAGS from /usr/${CHOST}/etc/portage/make.conf when cross-compiling for ${CHOST}, i.e. compiling a cross-${CHOST}/pkg package... *** Bug 449468 has been marked as a duplicate of this bug. *** *** Bug 450670 has been marked as a duplicate of this bug. *** cross-*/ packages are normally merged by host's portage into ROOT=/. libc arguably should never be merged by host's portage. But it's not how crossdev operates today (we'll fix it one day). Thus today's behaviour is aggressive host flags cleanup in cross-* ebuilds. Does it still fail to remove host's -march= today? newlib ebuilds should work just fine nowadays. https://bugs.gentoo.org/642604 will move libc out of cross-*/ post portage longer term. |