From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Nieuwenhuizen Subject: Re: avr-gcc Date: Fri, 15 Apr 2016 10:09:04 +0200 Message-ID: <878u0fs38f.fsf@drakenvlieg.flower> References: <87wptgmyv1.fsf@elephly.net> <87twoks459.fsf@gnu.org> <87a8qbr2mb.fsf@gnu.org> <87ziy8g3bp.fsf@gnu.org> <87a8kxfdgc.fsf@gnu.org> <87h9f4spw3.fsf@drakenvlieg.flower> <87twj4m92o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyor-00075Q-0r for guix-devel@gnu.org; Fri, 15 Apr 2016 04:09:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqyom-0003sQ-Sy for guix-devel@gnu.org; Fri, 15 Apr 2016 04:09:36 -0400 In-Reply-To: <87twj4m92o.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 14 Apr 2016 18:47:11 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Andy Wingo , "guix-devel@gnu.org" Ludovic Court=C3=A8s writes: [CC: Andy because it's his bug report] >> * gnu/packages/gcc (gcc): Use CPATH instead of C_INCLUDE_PATH. Fixes us= age 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 -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 --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.nl= =20=20