# HG changeset patch # User "Yann E. MORIN" # Date 1222637744 0 # Node ID 4653d6002d37dcff5eb19b84c4423e30b8c90fb7 # Parent 35302e8a34834e8bd393d29b3973555f6ee86d65 Had a new known issue: ccache will break the build because we're sym-linking to have our own compiler for host and build systems, but that screws up ccache finding the real compiler. There is no fix, so the only way to inform the users is to document it: remove ccache. /trunk/docs/known-issues.txt | 25 21 4 0 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff -r 35302e8a3483 -r 4653d6002d37 docs/known-issues.txt --- a/docs/known-issues.txt Sun Sep 28 21:34:11 2008 +0000 +++ b/docs/known-issues.txt Sun Sep 28 21:35:44 2008 +0000 @@ -44,10 +44,8 @@ x86 and for x86_64. Only the system part of the tuple (here, linux-gnu) needs to be the same to - trigger the bug. - - If you really cross-compile (eg x86 -> x86_64, or the other way around), - the toolchain builds successfully. + trigger the bug. Which means that building a tolchain for either x86 or + x86_64 on either x86 or x86_64 breaks. Fix: None known. @@ -57,3 +55,22 @@ Or investigate! :-) -------------------------------- +Symptoms: + gcc is not found, although I *do* have gcc installed. + +Explanations: + This is an issue on at least RHEL systems, where gcc is a symlink to ccache. + Because crosstool-NG create links to gcc for the build and host environment, + those symlinks are in fact pointing to ccache, which then doesn't know how + to run the compiler. + + A possible fix could probably set the environment variable CCACHE_CC to the + actual compiler used. + +Fix: + None known. + +Workaround: + Uninstall ccache. + +--------------------------------