[bug#39414] [PATCH 2/2] gnu: commencement: Rationalize search path handling.

[Ludovic Courtès]

Hello! :-)

Jan Nieuwenhuizen <address@hidden> skribis:

>>      (native-inputs `(("binutils" ,binutils-mesboot0)
>> -                     ("gcc" ,gcc-core-mesboot)
>> +
>> +                     ;; GCC-CORE-MESBOOT must appear last because it also
>> +                     ;; 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)
>>  
>>                       ("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-unknown-linux-gnu/2.95.3/include"
>> -                                           ":" kernel-headers "/include"
>> -                                           ":" glibc "/include"))
>> -                 (format (current-error-port) "C_INCLUDE_PATH=~a\n" (getenv 
>> "C_INCLUDE_PATH"))
>> -                 (format (current-error-port) "LIBRARY_PATH=~a\n" (getenv 
>> "LIBRARY_PATH"))
>> -                 ;; FIXME: add glibc dirs to paths manually
>> -                 (setenv "LIBRARY_PATH" (string-join
>> -                                         (list (string-append glibc "/lib")
>> -                                               (getenv "LIBRARY_PATH"))
>> -                                         ":"))
>> -                 (format (current-error-port) "LIBRARY_PATH=~a\n" (getenv 
>> "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='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 ‘gcc-core-mesboot’ from the search path.  I understood this
was because ‘gcc-core-mesboot’ contained libc headers (from Mes) and we
didn’t want them to shadow glibc headers.

So I first moved ‘gcc-core-mesboot’ down in the ordering, but then found
out that we could just remove the include/ directory from
‘gcc-core-mesboot’ altogether, which I did.

(I’ll fix the comment that says that ‘gcc-core-mesboot’ provides libc
headers from Mes because that’s no longer the case.)

>> -                 (setenv "C_INCLUDE_PATH" (string-append
>> -                                           gcc 
>> "/lib/gcc-lib/i686-unknown-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=~a\n" (getenv 
>> "C_INCLUDE_PATH"))
>> -                 (format (current-error-port) "LIBRARY_PATH=~a\n" (getenv 
>> "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 found 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 “mpfr/src” to
‘C_INCLUDE_PATH’.

>> -                     (setenv "C_INCLUDE_PATH" (string-append
>> -                                               gcc 
>> "/lib/gcc-lib/i686-unknown-linux-gnu/4.7.4/include"
>> -                                               ":" kernel-headers "/include"
>> -                                               ":" glibc "/include"
>> -                                               ":" (getcwd) "/mpfr/src"))
>> -                     (setenv "CPLUS_INCLUDE_PATH" (string-append
>> -                                                   gcc 
>> "/lib/gcc-lib/i686-unknown-linux-gnu/4.7.4/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=~a\n" 
>> (getenv "C_INCLUDE_PATH"))
>> -                     (format (current-error-port) "CPLUS_INCLUDE_PATH=~a\n" 
>> (getenv "CPLUS_INCLUDE_PATH"))
>> -                     (format (current-error-port) "LIBRARY_PATH=~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’ll have to see what can be done to not put these phases back in.

My approach was to start by looking at what the ‘set-paths’ phase prints
and see what was missing or incorrect in the values it computes.

Thanks for testing & reviewing!  I’ll push shortly.

Ludo’.