From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:51532) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izi3c-0002lT-Tp for guix-patches@gnu.org; Thu, 06 Feb 2020 09:23:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izi3Z-00052c-VJ for guix-patches@gnu.org; Thu, 06 Feb 2020 09:23:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41214) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izi3Z-00052N-Qn for guix-patches@gnu.org; Thu, 06 Feb 2020 09:23:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1izi3Z-00035Y-MT for guix-patches@gnu.org; Thu, 06 Feb 2020 09:23:01 -0500 Subject: [bug#39414] [PATCH 2/2] gnu: commencement: Rationalize search path handling. Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20200204130042.27757-1-ludo@gnu.org> <20200204130042.27757-2-ludo@gnu.org> <871rr85j1e.fsf@gnu.org> Date: Thu, 06 Feb 2020 15:22:37 +0100 In-Reply-To: <871rr85j1e.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Thu, 06 Feb 2020 07:25:33 +0100") Message-ID: <87zhdv7q36.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Jan Nieuwenhuizen Cc: 39414@debbugs.gnu.org Hello! :-) Jan Nieuwenhuizen skribis: >> (native-inputs `(("binutils" ,binutils-mesboot0) >> - ("gcc" ,gcc-core-mesboot) >> + >> + ;; GCC-CORE-MESBOOT must appear last because it al= so >> + ;; provides libc headers from Mes that we want to = shadow >> + ;; with those of GLIBC-MESBOOT0. >> ("libc" ,glibc-mesboot0) >> + ("kernel-headers" ,%bootstrap-linux-libre-headers) >> + ("gcc" ,gcc-core-mesboot) >>=20=20 >> ("bash" ,%bootstrap-coreutils&co) >> ("coreutils" ,%bootstrap-coreutils&co) >> ("diffutils" ,diffutils-mesboot) >> - ("kernel-headers" ,%bootstrap-linux-libre-headers) >> ("make" ,make-mesboot0))) > > Here it gets real interesting; it seems above you actually fix (or work > around?) a bug that allowed you to... [...] >> - (setenv "C_INCLUDE_PATH" (string-append >> - gcc "/lib/gcc-lib/i686-unkno= wn-linux-gnu/2.95.3/include" >> - ":" kernel-headers "/include" >> - ":" glibc "/include")) >> - (format (current-error-port) "C_INCLUDE_PATH=3D~a\n" (= getenv "C_INCLUDE_PATH")) >> - (format (current-error-port) "LIBRARY_PATH=3D~a\n" (ge= tenv "LIBRARY_PATH")) >> - ;; FIXME: add glibc dirs to paths manually >> - (setenv "LIBRARY_PATH" (string-join >> - (list (string-append glibc "/l= ib") >> - (getenv "LIBRARY_PATH")) >> - ":")) >> - (format (current-error-port) "LIBRARY_PATH=3D~a\n" (ge= tenv "LIBRARY_PATH")) >> - (with-output-to-file "config.cache" >> - (lambda _ >> - (display " >> + (lambda _ >> + (setenv "CONFIG_SHELL" (which "sh")) >> + (with-output-to-file "config.cache" >> + (lambda _ >> + (display " >> ac_cv_c_float_format=3D'IEEE (little-endian)' >> "))) >> - #t))) >> + #t)) > > remove this monster. Although I am especially happy with it, I am > unsure exactly how it works. I analyzed what the monster does: it constructs *PATH exactly like the search path machinery would do. The big difference I noticed was that it excluded =E2=80=98gcc-core-mesboot=E2=80=99 from the search path. I und= erstood this was because =E2=80=98gcc-core-mesboot=E2=80=99 contained libc headers (from= Mes) and we didn=E2=80=99t want them to shadow glibc headers. So I first moved =E2=80=98gcc-core-mesboot=E2=80=99 down in the ordering, b= ut then found out that we could just remove the include/ directory from =E2=80=98gcc-core-mesboot=E2=80=99 altogether, which I did. (I=E2=80=99ll fix the comment that says that =E2=80=98gcc-core-mesboot=E2= =80=99 provides libc headers from Mes because that=E2=80=99s no longer the case.) >> - (setenv "C_INCLUDE_PATH" (string-append >> - gcc "/lib/gcc-lib/i686-unkno= wn-linux-gnu/2.95.3/include" >> - ":" kernel-headers "/include" >> - ":" glibc "/include" >> - ":" (getcwd) "/mpfr/src")) >> - (setenv "LIBRARY_PATH" (string-append glibc "/lib" >> - ":" gcc "/lib")) >> - (format (current-error-port) "C_INCLUDE_PATH=3D~a\n" (= getenv "C_INCLUDE_PATH")) >> - (format (current-error-port) "LIBRARY_PATH=3D~a\n" (ge= tenv "LIBRARY_PATH")) >> - #t))) >> + (lambda _ >> + (setenv "CONFIG_SHELL" (which "sh")) >> + >> + ;; Allow MPFR headers to be found. >> + (setenv "C_INCLUDE_PATH" >> + (string-append (getcwd) "/mpfr/src:" >> + (getenv "C_INCLUDE_PATH"))) >> + >> + ;; Set the C++ search path so that C headers can be foun= d as >> + ;; libstdc++ is being compiled. >> + (setenv "CPLUS_INCLUDE_PATH" (getenv "C_INCLUDE_PATH")) >> + #t)) > > Similar here, Here I found that the only difference was adding =E2=80=9Cmpfr/src=E2=80=9D= to =E2=80=98C_INCLUDE_PATH=E2=80=99. >> - (setenv "C_INCLUDE_PATH" (string-append >> - gcc "/lib/gcc-lib/i686-u= nknown-linux-gnu/4.7.4/include" >> - ":" kernel-headers "/inc= lude" >> - ":" glibc "/include" >> - ":" (getcwd) "/mpfr/src"= )) >> - (setenv "CPLUS_INCLUDE_PATH" (string-append >> - gcc "/lib/gcc-lib/i6= 86-unknown-linux-gnu/4.7.4/include" >> - ":" kernel-headers "= /include" >> - ":" glibc "/include" >> - ":" (getcwd) "/mpfr/= src")) >> - (setenv "LIBRARY_PATH" (string-append glibc "/lib" >> - ":" gcc "/li= b")) >> - (format (current-error-port) "C_INCLUDE_PATH=3D~a\= n" (getenv "C_INCLUDE_PATH")) >> - (format (current-error-port) "CPLUS_INCLUDE_PATH= =3D~a\n" (getenv "CPLUS_INCLUDE_PATH")) >> - (format (current-error-port) "LIBRARY_PATH=3D~a\n"= (getenv "LIBRARY_PATH")) >> - #t)))))))))) >> + "--disable-build-with-cxx")))))))) > > and same here. Same story. > I tried your commit and it works for me. Rebasing `wip-bootstrap' onto > it was some work as you might imagine. The good news is that I finally > got it to "work" again (`wip-bootstrap' @ gitlab); the bad news is > that I have kept (or put back, actually) one of these 'setenv phases in > `gcc-mesboot0'. Well, that's for later worry; so this will need another > look when merging the scheme-only "wip-bootsrap". Yes, we=E2=80=99ll have to see what can be done to not put these phases bac= k in. My approach was to start by looking at what the =E2=80=98set-paths=E2=80=99= phase prints and see what was missing or incorrect in the values it computes. Thanks for testing & reviewing! I=E2=80=99ll push shortly. Ludo=E2=80=99.