[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 <http://bugs.gnu.org/22186> as the
> comment above explains.
Thanks, that's an interesting read; I didn't know about the
-Wsystem-path.
> 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
C*_INCLUDE_PATH and not CPATH?
> 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
everywhere?
Greetings,
Jan
--
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
- Re: avr-gcc, Thompson, David, 2016/04/12
- Re: avr-gcc, Thompson, David, 2016/04/12
- Re: avr-gcc, Ludovic Courtès, 2016/04/13
- Re: avr-gcc, Jan Nieuwenhuizen, 2016/04/14
- Re: avr-gcc, Ludovic Courtès, 2016/04/14
- Re: avr-gcc,
Jan Nieuwenhuizen <=
- Re: avr-gcc, Andy Wingo, 2016/04/15
- Re: avr-gcc, Jan Nieuwenhuizen, 2016/04/15
- Re: avr-gcc, Andy Wingo, 2016/04/15
- Re: avr-gcc, Ludovic Courtès, 2016/04/15
- Re: avr-gcc, Ludovic Courtès, 2016/04/15
- Re: avr-gcc, Jan Nieuwenhuizen, 2016/04/16