xinsan Chen wrote: > I unset the C_INCLUDE_PATH to an > empty string then the compilation proceeds further. > But I don't know why I must unset C_INCLUDE_PATH. > I then don't know why you must set it... A native GCC automatically searches these : >> C_INCLUDE_PATH=/usr/local/include:/usr/include >> in the same order. But the GCC build may think that your standard headers are in '/usr/local/include', not in '/usr/include'. You must have some reason for setting these things... >> LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH >> LIBRARY_PATH=/usr/local/lib:$LIBRARY_PATH >> But the '/usr/local/lib' wouldn't be searched for target (also host in the native case) libraries automatically if one changes the $prefix from the default '/usr/local'... If not, then the '$prefix/lib/gcc/$target/$gcc_version/../../../../lib' would be '/usr/local/lib' and being searched automatically... I remember this too being on the GCC's built-in search paths... So when you decide your special $prefix, you have some logic and reason for that. This is something like putting gasoline into a can and putting that can into the car and then wondering why the car cannot use the gasoline. My thought is that the chosen '$prefix/lib' could be expected logical place for your "local" library stuff.... >> ../.././gcc/../libcpp/include/line-map.h:66: error: 'CHAR_BIT' >> undeclared here (not in a function) >> >> I think CHAR_BIT is defined in /usr/include/limits.h but why it cannot >> be searched. >> The logic in "fixinc" is that if the target's standard headers have 'limits.h', the GCC's own 'limits.h' (seen first) will get wrapper which will '#include_next <limits.h>', ie the system's own 'limits.h'. In your case maybe the standard headers were searched from '/usr/local/include' and 'limits.h' wasn't found there :( The '$BUILD/gcc/xlimits.h' is the GCC's own (edited or not) 'limits.h', so looking at it tells whether the 'limits.h' in the standard headers was found or not...
