[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

Thiago Jung Bauermann schreef op vr 16-07-2021 om 17:01 [-0300]:
> Thanks! I did that but it doesn’t work in this case because the ‘source’
> functions expect a Nix system string and ‘%current-target-system’ is a
> GNU triplet string. After I defined a function which calls
> ‘gnu-triplet->nix-system’ on it, then it worked.
> 
> This made me realize that all places which do
> `(or (%current-target-system) (%current-system))` have this inconsistency.
> I’m currently preparing a couple of patches to clean them up.

There are some places where it doesn't matter if it's the GNU triplet
or Nix system string (e.g. libflame, tlsdate) and there are some places
where the difference does matter (e.g. the definition of libpasastro
seems buggy o me).

> The vast majority of the files are ppc64le. Of the x86-64 ones, 87 are in
> /tmp/guix-build-gcc-11.1.0.drv-0/build/build-x86_64-unknown-linux-gnu/ and
> 45 are in /tmp/guix-build-gcc-11.1.0.drv-0/build/gcc/build/.
> 
> I’m not very familiar with GCC’s build system, so I can’t say whether it’s
> expected to have it create these x86-64 objects, but I wouldn’t be surprised
> if it needed to build some native auxiliaryprograms for the build process.

When compiling GCC (version M) with GCC (version N), first version M is compiled
using version N, then the resulting gcc is used to compile GCC (version M) again.
As I understand it, the idea is to let the end result be independent from the
compiler one started out with.

> Because there’s no finished output, I wasn’t able to check for references.
> 
> I can make a more conclusive test when this GCC cross build problem is fixed.

Ok.

Greetings,
Maxime.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]