Re: Dealing with non-ASCII file names in BOOTSTRAP-ORIGIN

[Greg Hogan]

Marius,

Thank you for your work upgrading the core packages!

On the off chance that the following is helpful, in order to switch
the build to GCC 11 or 12 I had to apply the patch (with the missing
endif) from
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c12

You may have avoided or worked around this issue, but even though a
different fix from the ticket was patched into our GCC 11.3 and 12.1,
these would not bootstrap for me without that patch.

Greg

On Mon, Jul 18, 2022 at 3:49 PM Marius Bakke <marius@gnu.org> wrote:
>
> Hi Guix,
>
> I tried switching to GCC 11 on the core-updates branch, but it fails
> early when attempting to repack the GCC source code for GCC-BOOT0,
> because some files in its test suite contains non-ASCII characters:
>
> --8<---------------cut here---------------start------------->8---
> [... unpacking ...]
> patching file gcc/builtins.c
> Hunk #1 succeeded at 4623 with fuzz 1 (offset 1341 lines).
> Hunk #2 succeeded at 6097 with fuzz 2 (offset 2206 lines).
> patching file gcc/gimple-fold.c
> Hunk #1 succeeded at 665 (offset 9 lines).
> Hunk #2 succeeded at 766 with fuzz 2 (offset 16 lines).
> patching file libvtv/Makefile.in
> Hunk #1 succeeded at 14 with fuzz 1 (offset -1 lines).
> source is at 'gcc-11.3.0'
> applying 
> '/gnu/store/g0ba4l825z9i4l1jd5cqvl6m09xicdwa-gcc-9-strmov-store-file-names.patch'...
> applying 
> '/gnu/store/5705r4ajxl8lav1hz9xm19w75zdcz1n2-gcc-5.0-libvtv-runpath.patch'...
> find-files: 
> gcc-11.3.0/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go: No 
> such file or directory
> Backtrace:
> In srfi/srfi-1.scm:
>  465: 19 [fold #<procedure 143cb10 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> ...]
> In ice-9/ftw.scm:
>  452: 18 [#<procedure 143cb10 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> # #]
>  450: 17 [loop "gcc" "gcc-11.3.0" ...]
> In srfi/srfi-1.scm:
>  465: 16 [fold #<procedure 2375210 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> ...]
> In ice-9/ftw.scm:
>  452: 15 [#<procedure 2375210 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> # #]
>  450: 14 [loop "testsuite" "gcc-11.3.0/gcc" ...]
> In srfi/srfi-1.scm:
>  465: 13 [fold #<procedure ebad80 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> ...]
> In ice-9/ftw.scm:
>  452: 12 [#<procedure ebad80 at ice-9/ftw.scm:451:38 (subdir result+visited)> 
> # #]
>  450: 11 [loop "go.test" "gcc-11.3.0/gcc/testsuite" ...]
> In srfi/srfi-1.scm:
>  465: 10 [fold #<procedure 219a4b0 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> ...]
> In ice-9/ftw.scm:
>  452: 9 [#<procedure 219a4b0 at ice-9/ftw.scm:451:38 (subdir result+visited)> 
> # #]
>  450: 8 [loop "test" "gcc-11.3.0/gcc/testsuite/go.test" ...]
> In srfi/srfi-1.scm:
>  465: 7 [fold #<procedure 229ba80 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> ...]
> In ice-9/ftw.scm:
>  452: 6 [#<procedure 229ba80 at ice-9/ftw.scm:451:38 (subdir result+visited)> 
> # #]
>  450: 5 [loop "fixedbugs" "gcc-11.3.0/gcc/testsuite/go.test/test" ...]
> In srfi/srfi-1.scm:
>  465: 4 [fold #<procedure 20bab70 at ice-9/ftw.scm:451:38 (subdir 
> result+visited)> ...]
> In ice-9/ftw.scm:
>  452: 3 [#<procedure 20bab70 at ice-9/ftw.scm:451:38 (subdir result+visited)> 
> # #]
>  474: 2 [loop "issue27836.dir" ...]
> In guix/build/utils.scm:
>  540: 1 [#<procedure d188e0 at guix/build/utils.scm:536:28 (file stat errno 
> result)> 
> "gcc-11.3.0/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go" ...]
> In unknown file:
>    ?: 0 [scm-error misc-error #f "~A" ("find-files failed") #f]
>
> ERROR: In procedure scm-error:
> ERROR: find-files failed
> --8<---------------cut here---------------end--------------->8---
>
> Deleting these files also don't work for the same reason, even when
> using the hex representation, i.e. (delete-file "\u00c4foo.go"), or with
> DELETE-FILE-RECURSIVELY.
>
> One workaround is to avoid the use of BOOTSTRAP-ORIGIN by applying the
> patches and snippet in phases, but that's suboptimal because it has to
> be done for all of GCC-BOOT0, LIBSTDC++, and GCC-FINAL.
>
> I'll try this workaround to get things going, but hoping for better
> suggestions!
>