Andy Wingo writes:
>> The problem is our usage of C_INCLUDE_PATH.
>
> I don't understand this diagnosis. If the paths were not in
> C_INCLUDE_PATH, they would be in CPATH. Then you'd have the same
> problem. No?
Let me try to choose my words more carefully. The facts that gcc sets
C_INCLUDE_PATH and this native gcc setting this path to the native
headers, is added to the environment when cross building, and the
fact that C_INCLUDE_PATH does not get special treatment when
cross building, like CPATH
- add_env_var_paths ("CPATH", BRACKET);
+ add_env_var_paths ("CROSS_CPATH", BRACKET);
makes that the cross-gcc picks up the wrong native headers unless
C_INCLUDE_PATH is unset.
> Or is there some special logic which is applying to CPATH which is not
> applying to C_INCLUDE_PATH?
Ah, yes; CPATH is not used when cross building, instead CROSS_CPATH is
used.
> Basically in Guix we should, IMO, always be working on C_INCLUDE_PATH
> and friends, and never on CPATH.
I'm guessing that could work; would could try to change the above patch
(in gcc-cross-environment-variables.patch) to handle C*_INCLUDE_PATH and
introduce CROSS_C*_INCLUDE_PATH.
I just wonder if there was another reason for cross builds to choose
CPATH/CROSS_CPATH instead of C_*INCLUDE_PATH. Apart maybe from the
fact that we would need to handle all `*' where CPATH works for all
languages.
Greetings,
Jan
--
Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
