Package: guix;
Reported by: Mathieu Othacehe <m.othacehe <at> gmail.com>
Date: Fri, 6 Mar 2020 07:38:01 UTC
Severity: normal
Done: Mathieu Othacehe <mathieu <at> cervin.i-did-not-set--mail-host-address--so-tickle-me>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Ludovic Courtès <ludo <at> gnu.org> To: Mathieu Othacehe <m.othacehe <at> gmail.com> Cc: Marius Bakke <mbakke <at> fastmail.com>, 39941 <at> debbugs.gnu.org Subject: bug#39941: Disk-image size increase on core-updates. Date: Tue, 24 Mar 2020 11:54:17 +0100
Hi,
Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:
>> Perhaps add “Fixes <https://bugs.gnu.org/39941>.”
>
> Well I think it doesn't. In the bug report 39941, I reported a recent
> increase of the cross-compiled disk-image on core-updates (1.5 -> 2.0
> GiB), over the last two months. It is not resolved, and this patch fixes
> something that has always been around I guess.
OK.
>>> + ;; TOOLDIR_BASE_PREFIX is erroneous when using a separate "lib"
>>> + ;; output. Specify it correctly, otherwise GCC won't find its shared
>>> + ;; libraries installed in the "lib" output.
>>
>> How erroneous is it? Is there a bug report we could link to?
>
> I didn't find any bug report related. The issue is that in
> gcc/Makefile.in, when computing libsubdir_to_prefix:
>
> libsubdir_to_prefix := \
> $(unlibsubdir)/$(shell echo "$(libdir)" | \
> sed -e 's|^$(prefix)||' -e 's|/$$||' -e 's|^[^/]|/|' \
> -e 's|/[^/]*|../|g')
>
>
> unlibsubdir is ../../../
> libdir /gnu/store/xxx-gcc-cross-aarch64-linux-gnu-7.5.0-lib/lib
> prefix is /gnu/store/yyy-gcc-cross-aarch64-linux-gnu-7.5.0
>
> then,
>
> libsubdir_to_prefix = ../../../../../..
>
> Which then gives a search path that looks like:
>
> /gnu/store/5qh73asm77554wj43z2wjdrkl3fjxxbp-gcc-cross-aarch64-linux-gnu-7.5.0-lib/lib/gcc/aarch64-linux-gnu/7.5.0/../../../../../../../aarch64-linux-gnu/lib/aarch64-linux-gnu/7.5.0/
>
> So its just that this hack is completely broken for non FHS compliant
> path I guess.
Uh. Perhaps just link to this bug report in the file, then.
> Note that on our native toolchain, we have the same issue. If you run:
>
> `guix build -e '(@@ (gnu packages gcc) gcc-9)'|tail -1`/bin/gcc -print-search-dirs
>
>
> You can see the same kind of wrong path:
>
> /gnu/store/347y0zr1a9s2f5pkcncgi3gd0r33qq81-gcc-9.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/9.2.0/../../../../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/9.2.0/
>
>
> and it still works, because of this snippet in GCC, disabled when
> cross-compiling:
>
> else if (*cross_compile == '0')
> {
> add_prefix (&startfile_prefixes,
> concat (gcc_exec_prefix
> ? gcc_exec_prefix : standard_exec_prefix,
> machine_suffix,
> standard_startfile_prefix, NULL),
> NULL, PREFIX_PRIORITY_LAST, 0, 1);
> }
>
>
> that produces an extra search-path that looks like:
>
> /gnu/store/347y0zr1a9s2f5pkcncgi3gd0r33qq81-gcc-9.2.0-lib/lib/gcc/x86_64-unknown-linux-gnu/9.2.0/../../../
>
> In short, quite a big mess...
Woow. Indeed.
> From 31402fc14126f04e175081ce851e9794cc3ab218 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe <at> gmail.com>
> Date: Sat, 14 Mar 2020 11:39:52 +0100
> Subject: [PATCH] gnu: cross-gcc: Add a "lib" output.
>
> Add a "lib" output to cross-gcc. This requires an upstream GCC patch adding
> support for --with-toolexeclibdir configure option. This option allows to
> install cross-built GCC libraries in a specific location.
>
> This also fixes the computation of TOOLDIR_BASE_PREFIX, that fails when
> /gnu/store/... directories are involved.
>
> * gnu/packages/patches/gcc-7-cross-toolexeclibdir.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/cross-base.scm (cross-gcc)[source]: Apply it,
> [outputs]: add a "lib" output,
> (cross-gcc-snippet): fix TOOLDIR_BASE_PREFIX.
[...]
> + (append (cond
> + ((version>=? (package-version xgcc) "8.0")
> + (search-patches "gcc-8-cross-environment-variables.patch"))
> + ((version>=? (package-version xgcc) "6.0")
> + (search-patches "gcc-7-cross-toolexeclibdir.patch"
> + "gcc-6-cross-environment-variables.patch"))
> + (else (search-patches "gcc-cross-environment-variables.patch")))
The indentation is off here.
> +++ b/gnu/packages/patches/gcc-7-cross-toolexeclibdir.patch
> @@ -0,0 +1,1677 @@
> +This patch taken from GCC upstream adds support for overriding cross-compiled
> +shared libraries installation path. This is needed to have a separate "lib"
> +output containing those shared libraries.
> +
> +See:
> +https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8e66971cdc6d1390d47a227899e2e340ff44d66
> +
> +This commit has been stripped. Some modifications to Changelogs and
> +configure.ac scripts were removed.
I think we can still remove the M4 files as well as changes to unrelated
‘configure’ scripts
> +From fe6b5640a52a6e75dddea834e357974c205c737c Mon Sep 17 00:00:00 2001
> +From: "Maciej W. Rozycki" <macro <at> wdc.com>
> +Date: Fri, 24 Jan 2020 11:24:25 +0000
> +Subject: [PATCH] Add `--with-toolexeclibdir=' configuration option
> +
> +Provide means, in the form of a `--with-toolexeclibdir=' configuration
> +option, to override the default installation directory for target
> +libraries, otherwise known as $toolexeclibdir. This is so that it is
> +possible to get newly-built libraries, particularly the shared ones,
> +installed in a common place, so that they can be readily used by the
> +target system as their host libraries, possibly over NFS, without a need
> +to manually copy them over from the currently hardcoded location they
> +would otherwise be installed in.
> +
> +In the presence of the `--enable-version-specific-runtime-libs' option
> +and for configurations building native GCC the option is ignored.
[...]
> +--- a/libgcc/configure
> ++++ b/libgcc/configure
I suspect this is the only file we need to patch, no? At least, we can
remove all the m4 and m4-related Makefile.in changes and the unrelated
‘configure’ changes.
Thanks,
Ludo’.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.