I just realized new icecream is not used anymore for any compilations triggered by emerge / portage. This is because the CHOST-named compiler is called (e.g. x86_64-pc-linux-gnu-g++) and not g++ directly. In the pre-1.0-ebuilds, this was worked around with the icecream-config-script, which generated the wrappers also for CHOST (but e.g. did not include clang{,++}). I can confirm that creating the appropriate symlinks in /usr/libexec/icecc/bin, portage uses icecc again and all works as expected. If this change makes it into the ebuild, a final message as was present in the older ebuilds might be nice (advising the user to add "/usr/libexec/icecc/bin" to PREROOTPATH in make.conf to allow portage to make use of icecream). Reproducible: Always
Would not be easier if you want to use the icecream just set CC=gcc and so on rather than create magic within the ebuild for symlinks?
(In reply to comment #1) > Would not be easier if you want to use the icecream just set CC=gcc and so > on rather than create magic within the ebuild for symlinks? This might be easier, but is unsupported and discouraged if I am not mistaken. See e.g. http://www.gentoo.org/doc/en/distcc.xml , which states (concerning setting CC, CXX etc. to specific values): "Doing this explicitly redefines some behaviour of Portage and may have some weird results in the future. Only do this if you're mixing CHOSTs." For that reason, the old icecream-ebuilds (pre 1.0.0) worked very similar to the ccache ebuild, which also generates the CHOST-symlinks from within the ebuild, using a ccache-config script. Before the 1.0.0-ebuild, icecream-ebuilds behaved very similar, the config-script was only missing support for clang{,++}. The 1.0.0 ebuild just dropped this script, which is also useful to support different CHOSTs for easy cross-compiling as explained in http://dev.gentoo.org/~rane/icecream.xml .
have you looked in /usr/lib/icecc/bin/ this is my PREEROOTPATH in my make.conf localhost bin # ls -ltr /usr/lib/icecc/bin/ insgesamt 0 lrwxrwxrwx 1 root root 14 3. Jan 22:22 gcc -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 3. Jan 22:22 cc -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 3. Jan 22:22 c++ -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 3. Jan 22:22 x86_64-pc-linux-gnu-gcc -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 3. Jan 22:22 g++ -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 3. Jan 22:22 x86_64-pc-linux-gnu-g++ -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 3. Jan 22:22 x86_64-pc-linux-gnu-c++ -> /usr/bin/icecc vs. localhost bin # ls -ltr /usr/libexec/icecc/bin insgesamt 0 lrwxrwxrwx 1 root root 14 16. Mai 14:54 gcc -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 16. Mai 14:54 g++ -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 16. Mai 14:54 clang++ -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 16. Mai 14:54 clang -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 16. Mai 14:54 cc -> /usr/bin/icecc lrwxrwxrwx 1 root root 14 16. Mai 14:54 c++ -> /usr/bin/icecc localhost bin # equery b /usr/lib/icecc/bin/x86_64-pc-linux-gnu-gcc * Searching for /usr/lib/icecc/bin/x86_64-pc-linux-gnu-gcc ... sys-devel/icecream-1.0.0-r1 (/usr/bin/icecc) from file date i had sugessted it's from sys-devel/icecream-0.97-r1 Now i'm confused
(In reply to comment #3) > Now i'm confused No need to! > have you looked in /usr/lib/icecc/bin/ this is my PREEROOTPATH in my > make.conf This is the old folder which was used by pre-icecream-1.0.0.ebuild versions. It is sadly not deleted on upgrade, as it was created and filled with symlinks during postinstall by sys-devel/icecream-0.97-r1 and is thus not picked up by portage, so it will stay floating on all upgraded systems :-(. You should use /usr/libexec/icecc/bin with sys-devel/icecream-1.0.0-r1, which it sadly does not tell you (unlike the older ebuilds, which did...). > /usr/libexec/icecc/bin This is the folder created by sys-devel/icecream-1.0.0-r1, which contains clang{,++} in addition now, but is missing the CHOST-symlinks, quick fix is to add them there manually until someone resolves this bug...
So is this fixed or not? I recently unmasked icecream-1.0.0-r1 on a few of my computers figuring this had long since been resolved, but I noticed that my emerge world builds weren't employing icecream to distribute compile jobs, and they were taking a long time. I'm going back to 0.9.7-r1 for the time being. Just curious on the status of this bug.
Pals, please have a look to #536746 Seems that we are near to finish this issue.
The issue described here seems to be resolved also for the in-tree version by the recent change to use dev-util/shadowman to create the compiler wrapper links in a common way.
(In reply to Oliver Freyermuth from comment #7) > The issue described here seems to be resolved also for the in-tree version > by the recent change to use dev-util/shadowman to create the compiler > wrapper links in a common way.
