Summary: | sys-apps/portage: emerge: NOCOLOR functionality does not work with gcc-4.9 | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Agostino Sarubbo <ago> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | linux-gpib-3.2.21-r1:20151109-113628.log |
Description
Agostino Sarubbo
![]() Created attachment 416356 [details]
linux-gpib-3.2.21-r1:20151109-113628.log
example
Is that GCC_COLORS variable set? You can add -fdiagnostics-color=never to CFLAGS. (In reply to Zac Medico from comment #2) > Is that GCC_COLORS variable set? You can add -fdiagnostics-color=never to > CFLAGS. GCC_COLORS is not set. Should it be? -fdiagnostics-color=never does not suppress all colors.. i don't see anything for toolchain@ to do here, so dropping cc. if portage wants to propagate NOCOLORS=1 into also exporting GCC_COLORS=, that sounds fine. It says here that setting GCC_COLORS to an empty string will disable colors: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html You can also try -fno-diagnostics-color in CFLAGS. (In reply to Zac Medico from comment #5) right ... that should be fairly safe for portage to do rather than trying to detect whether the active compiler supports the flag |