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

[Thiago Jung Bauermann via Guix-patches via <guix-patches@gnu.org>]

Em domingo, 18 de julho de 2021, às 13:10:40 -03, Maxime Devos escreveu:
> 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).

True. I’m going through the places using ‘%current-target-system’ and 
fixing the ones that seem buggy to me. I changed libpasastro here. I should 
have something to send in the next few days.

> > 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.

Makes sense. Thanks for clarifying!

-- 
Thanks,
Thiago