bug#39941: Disk-image size increase on core-updates.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Mathieu Othacehe <m.othacehe@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@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@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’.