dev-util/colorgcc-1.3.2-r4 hangs when called directly. user@edison ~ $ colorgcc ^C user@edison ~ $ colorgcc-1.3.2 gcc: no input files whereas colorgcc-1.3.2 is the vanilla version pulled from http://schlueters.de/colorgcc.html Reproducible: Always Steps to Reproduce: 1. install dev-util/colorgcc-1.3.2-r4 2. execute 'colorgcc' Actual Results: hangs Expected Results: Output: 'gcc: no input files'
Er, what if you set CC=colorgcc and then ran ./configure and make somewhere? Or how about you tried and used it as intended - as a wrapper for gcc - the URL you pointed out has a neat example where, instead of calling gcc directly, colorgcc is called with the very same arguments. :)
Yes, indeed, colorgcc is a wrapper for gcc. There are multiple ways of invoking it, all resulting in the replacement the compiler commands with colorgcc, which in turn invokes the desired command. Possible solutions are: 1) use a softlink in a directory earlier in the $PATH that the compilers 2) use aliases 3) use environment variables Either way, colorgcc it executed and should call gcc. Thus, when I execute colorgcc, it should behave like a gcc without any parameters. The expected output is, as described above, 'gcc: no input files'. This does not work. I only described the simplest test here, other test fail as well (the script simply hangs).
Seems to me to be its default behaviour - when called as colorgcc, it simply returns stdin: /usr/bin/colorgcc:226:# If called as "colorgcc", just filter STDIN to STDOUT. epia ~ # /usr/bin/colorgcc foo foo bar bar baz baz and so on. If, for instance, you called /usr/lib/colorgcc/bin/cc instead, you'd see this: epia ~ # /usr/lib/colorgcc/bin/cc gcc: no input files
Apparently, the gentoo version has a different default behaviour from the vanilla version from the web. Originally, colorgcc defaults to call gcc when called directly. The gentoo version hangs and mirrors stdin. This makes it impossible by executing colorgcc via alias. Even makefile which simply include calls like $CC .. do not work. Only linking works - it seems to be the only possible way to get colorgcc recognizing desired compiler. So although colorgcc works nicely with links, it differs alot from default behaviour found on the web (ie. the simple example from http://schlueters.de/colorgcc.html does not work). This sould be adressed or at least noted in the ebuild messages. Additionally, a hint to the installed files in /usr/lib/colorgcc/bin might be useful...
Created attachment 288891 [details, diff] colorgcc-bug234166.patch This patch tries to restore the default behavior. It does it by checking if the program name matches /^colorgcc[-0-9.]*(\.pl)?$/, so it should support the most common filenames: colorgcc, colorgcc.pl, colorgcc-1.2.3, colorgcc-1.2.3.pl. If the program name matches, "gcc" compiler is assumed. If the program name does not match that expression, the Gentoo code (that searches the PATH for the appropriate compiler) gets run. The patch should be applied after those other gentoo patches. This is my first time editing Perl code, so it would be better to someone double-check it.
commit bee63f0 (HEAD, master) Author: Patrice Clement <monsieurp@gentoo.org> Date: Fri Sep 25 20:40:19 2015 +0000 dev-util/colorgcc: Add patch to keep colorgcc from hanging when invoked at the CLI. Fixes bug 234166. Package-Manager: portage-2.2.18 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> create mode 100644 dev-util/colorgcc/colorgcc-1.3.2-r7.ebuild create mode 100644 dev-util/colorgcc/files/colorgcc-1.3.2-nohang.patch Thank you for your patch.
