Re: avr-gcc

[Jan Nieuwenhuizen <janneke@gnu.org>]

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 <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl