From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Nieuwenhuizen Subject: Re: [PATCH v4 1/9] gnu: cross: Use CROSS_*_INCLUDE_PATH for system headers. Date: Tue, 26 Apr 2016 10:37:40 +0200 Message-ID: <87shy8ydd7.fsf@drakenvlieg.flower> References: <87vb492l7s.fsf@drakenvlieg.flower> <87r3eq2y2s.fsf@drakenvlieg.flower> <8760w2nzl4.fsf@elephly.net> <87d1q8lb7j.fsf@drakenvlieg.flower> <87k2k99l7w.fsf@gnu.org> <87d1pssnwl.fsf@drakenvlieg.flower> <871t614pk6.fsf@gnu.org> <87bn4yhurl.fsf_-_@drakenvlieg.flower> <87vb36x9ac.fsf@igalia.com> <87vb492l7s.fsf@drakenvlieg.flower> <877fgio11v.fsf@elephly.net> <87r3eq2y2s.fsf@drakenvlieg.flower> <8760w2nzl4.fsf@elephly.net> <87d1q8lb7j.fsf@drakenvlieg.flower> <87k2k99l7w.fsf@gnu.org> <87d1pssnwl.fsf@drakenvlieg.flower> <871t614pk6.fsf@gnu.org> <87bn4yhurl.fsf_-_@drakenvlieg.flower> <87vb36x9ac.fsf@igalia.com> <87wpnmgc5k.fsf@drakenvlieg.flower> <87oa8wx0jg.fsf@igalia.com> 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]:47995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auyVS-0002g2-BE for guix-devel@gnu.org; Tue, 26 Apr 2016 04:38:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1auyVP-0007fe-5e for guix-devel@gnu.org; Tue, 26 Apr 2016 04:38:06 -0400 In-Reply-To: <87oa8wx0jg.fsf@igalia.com> (Andy Wingo's message of "Tue, 26 Apr 2016 10:00:03 +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: Andy Wingo Cc: guix-devel@gnu.org Andy Wingo writes: > Well, you had two versions there, and the second one that just used let* > looked fine to me. Dunno. I find that the structure imposed by > and-let* tends to contort things in a way I don't want -- sometimes it's > only some of the bindings that I want to test for truthiness. I find > myself fighting and-let* more than enjoying it. Anyway. It is a very > minor point and I don't think it matters here :) Okay. >> - (let ((libc (assoc-ref inputs "libc")) >> + (let ((libc (assoc-ref inputs libc)) >> (linux (assoc-ref inputs "xlinux-headers"))) > > FYI while I usually don't vertically line up subexpressions, it would > appear to be the guix style ;) So this edit undoes some valid code. I > don't think it matters though. There's something wrong here that I keep correcting, I'll have a look. I think it should be "libc" ... I have wondered about a patch where I change libc to "libc" -- how did that ever work? Apparently, I broke it here. > OK so this is literally a patch in a patch and it gets complicated to > review :) But cool, I had a question about one piece: What I did was import gcc-4.9.3 into git, applied the original gcc-cross-environment-variables.patch from Guix, made some changes and used git to produce a new gcc-cross-environment-variables.patch. I'm not too happy with this, maybe I should look into making the guix patch-in-patch nicer? Anyway, here inline is the actual diff between the original gcc-cross-environment-variables.patch and the new one: diff --git a/gcc/incpath.c b/gcc/incpath.c index 3a34998..ba12249 100644 --- a/gcc/incpath.c +++ b/gcc/incpath.c @@ -461,8 +461,8 @@ register_include_chains (cpp_reader *pfile, const char = *sysroot, int stdinc, int cxx_stdinc, int verbose) { static const char *const lang_env_vars[] =3D - { "C_INCLUDE_PATH", "CPLUS_INCLUDE_PATH", - "OBJC_INCLUDE_PATH", "OBJCPLUS_INCLUDE_PATH" }; + { "CROSS_C_INCLUDE_PATH", "CROSS_CPLUS_INCLUDE_PATH", + "CROSS_OBJC_INCLUDE_PATH", "CROSS_OBJCPLUS_INCLUDE_PATH" }; cpp_options *cpp_opts =3D cpp_get_options (pfile); size_t idx =3D (cpp_opts->objc ? 2: 0); =20 diff --git a/gcc/tlink.c b/gcc/tlink.c index 65d4a84..ad6242f 100644 --- a/gcc/tlink.c +++ b/gcc/tlink.c @@ -458,7 +458,7 @@ recompile_files (void) file *f; =20 putenv (xstrdup ("COMPILER_PATH=3D")); - putenv (xstrdup (LIBRARY_PATH_ENV "=3D")); + putenv (xstrdup ("LIBRARY_PATH_ENV=3D")); =20 while ((f =3D file_pop ()) !=3D NULL) { > The Scheme parts LGTM; would you mind giving details about the GCC > patch? You spotted the putenv problem, quite visible above; I'm not sure why this still works for me, I'll fix (i.e., revert) this. As to your other two questions about if (temp): those are actually not changes wrt the current gcc-cross-environment-variables.patch. >> +- if (temp && *cross_compile =3D=3D '0') >> ++ if (temp) >> + { >> + const char *startp, *endp; >> + char *nstore =3D (char *) alloca (strlen (temp) + 3); > > Why this change? Not a change per se, AIUI our cross patch makes COMPILER_PATH now valid, as we populate it from CROSS_*. >> +#define LIBRARY_PATH_ENV "CROSS_LIBRARY_PATH" >> + >> #endif /* ! GCC_SYSTEM_H */ >> - > > I wasn't quite able to understand this bit. >> - putenv (xstrdup ("LIBRARY_PATH=3D")); >> -+ putenv (xstrdup (LIBRARY_PATH_ENV "=3D")); >> ++ putenv (xstrdup ("LIBRARY_PATH_ENV=3D")); >>=20=20=20 >> while ((f =3D file_pop ()) !=3D NULL) >> { > > Surely this is incorrect? Oops yes, this is wrong. Thanks >> -- if (temp && *cross_compile =3D=3D '0') >> -+ if (temp) >> - { >> - const char *startp, *endp; >> - char *nstore =3D (char *) alloca (strlen (temp) + 3); >> --=20 >> 2.7.3 > > Similar comment as above. Not a change per se, AIUI our cross patch makes LIBRARY_PATH[_ENV] now valid, as we populate it from CROSS_LIBRARY_PATH. Thanks again, greetings, Jan --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.nl= =20=20