[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: avr-gcc

From: Jan Nieuwenhuizen
Subject: Re: avr-gcc
Date: Fri, 15 Apr 2016 10:09:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ludovic Courtès writes:

[CC: Andy because it's his bug report]

>> * gnu/packages/gcc (gcc): Use CPATH instead of C_INCLUDE_PATH.  Fixes usage 
>> of
>>   native glibc headers when cross-compiling.
> This would be reverting the fix for <> as the
> comment above explains.

Thanks, that's an interesting read; I didn't know about the

> I suppose the problem is that CPATH is still used elsewhere, leading
> to interference with this one.

The problem is our usage of C_INCLUDE_PATH.  Before I found this
apparently simple solution I proposed (not knowing about this bug
report), I gained some experience with what happens if we have the
native gcc set C_INCLUDE_PATH.

When cross building the function build-system/gnu.scm
(standard-packages) includes the native gcc into the build environment.
This makes C_INCLUDE_PATH to point to the native glibc.  That breaks
early when cross compiling to a non-glibc platform such as mingw.

Then I wrote a package-dependent version of standard-packages, that
--when cross-compiling non-toolchain packages--does not include the
native gcc.  Ugly and clumly but works.

Except for packages that need a native gcc to build tools during build
time (CC_FOR_BUILD).  For such packages (like Bash or Guile),
standard-packages must include gcc again.  Then, the build recipe's
phases must be changed so that when cross compiling, the
C_INCLUDE_PATH is moved into CPATH and C_INCLUDE_PATH is unset.
That makes this solution even more unattractive, many changes
to package recipe's could be needed.

However, the bug report by Andy suggests that this is somehow also
the wrong solution, even when cross compiling you'd want to use

> However, the cross-compilers for mips64el-linux-gnu and
> armhf-linux-gnueabi work fine, AFAIK.

Are these platforms also using glibc, that could possibly hide a problem
of including the wrong headers?

> Thoughts?

I would like to ask you (all) the same question.  I don't really
know at this point which way to go.

Possibly we can change gcc-cross-environment-variables.patch
to do this trick

    -  add_env_var_paths ("CPATH", BRACKET);
    +  add_env_var_paths ("CROSS_CPATH", BRACKET);

to C_*INCLUDE_PATH instead of to CPATH, and use C_*INCLUDE_PATH


Jan Nieuwenhuizen <address@hidden> | GNU LilyPond
Freelance IT | Avatar®  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]