From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#39941: Disk-image size increase on core-updates. Date: Tue, 24 Mar 2020 11:54:17 +0100 Message-ID: <87y2rqm3ae.fsf@gnu.org> References: <87sgimdjcj.fsf@gmail.com> <87eeu0h8d6.fsf@gmail.com> <87a74nhstf.fsf@gnu.org> <87zhcnympn.fsf@gmail.com> <87r1xyfx7o.fsf@gnu.org> <87a74jnr4f.fsf@gmail.com> <87y2s3ktkn.fsf@devup.no> <875zf5lv79.fsf@gmail.com> <87tv2pilrj.fsf@gnu.org> <87pndbb4py.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58138) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGhD6-00049T-LT for bug-guix@gnu.org; Tue, 24 Mar 2020 06:55:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jGhD4-0001Ha-8c for bug-guix@gnu.org; Tue, 24 Mar 2020 06:55:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47994) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jGhD4-0001HN-3x for bug-guix@gnu.org; Tue, 24 Mar 2020 06:55:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jGhD4-0003u5-2J for bug-guix@gnu.org; Tue, 24 Mar 2020 06:55:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87pndbb4py.fsf@gmail.com> (Mathieu Othacehe's message of "Tue, 17 Mar 2020 12:28:25 +0100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Mathieu Othacehe Cc: 39941@debbugs.gnu.org Hi, Mathieu Othacehe skribis: >> Perhaps add =E2=80=9CFixes .=E2=80=9D > > 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 sha= red >>> + ;; 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 :=3D \ > $(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 =3D ../../../../../.. > > 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-s= earch-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/x= 86_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 =3D=3D '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 > 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 addi= ng > 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>=3D? (package-version xgcc) "8.0") > + (search-patches "gcc-8-cross-environment-variabl= es.patch")) > + ((version>=3D? (package-version xgcc) "6.0") > + (search-patches "gcc-7-cross-toolexeclibdir.patc= h" > + "gcc-6-cross-environment-variabl= es.patch")) > + (else (search-patches "gcc-cross-environment-var= iables.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-com= piled > +shared libraries installation path. This is needed to have a separate "= lib" > +output containing those shared libraries. > + > +See: > +https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3De8e66971cdc6d1390d47= a227899e2e340ff44d66 > + > +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 =E2=80=98configure=E2=80=99 scripts > +From fe6b5640a52a6e75dddea834e357974c205c737c Mon Sep 17 00:00:00 2001 > +From: "Maciej W. Rozycki" > +Date: Fri, 24 Jan 2020 11:24:25 +0000 > +Subject: [PATCH] Add `--with-toolexeclibdir=3D' configuration option > + > +Provide means, in the form of a `--with-toolexeclibdir=3D' 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 =E2=80=98configure=E2=80=99 changes. Thanks, Ludo=E2=80=99.