Hi, Mathieu Othacehe <m.othac...@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.othac...@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" <ma...@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’.
