The guix pull profile is too big

  • Open
  • quality assurance status badge
Details
6 participants
  • bokr
  • Julien Lepiller
  • Ludovic Courtès
  • Maxime Devos
  • (
  • zimoun
Owner
unassigned
Submitted by
Julien Lepiller
Severity
normal
J
J
Julien Lepiller wrote on 17 Jun 2022 07:48
(address . bug-guix@gnu.org)
2C6CCC4B-BC71-4CA4-9B7B-086C14713DCD@lepiller.eu
Hi Guix!

I figured out this morning that my guix pull profile ("current") was more than 1GB. Looking at the closure, I found a few oddities.

There's gcc in there, which is the second most important contributor after guix-*-modules (150 MB). It's referenced by gcc-toolchain, itself only referenced by the guile-wrapper we build in (guix self). Can we get rid of it?

There are three versions of guile (50 MB each). Can we settle for only one?

Then maybe less important because they're small:

There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and libunistring.

We have bash-minimal and bash-static. The latter is a bit bigger than the former. Maybe we can keep only bash-minimal?
Attachment: file
L
L
Ludovic Courtès wrote on 26 Jun 2022 23:20
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 56030@debbugs.gnu.org)
87h747qfyr.fsf@gnu.org
Hi,

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (2 lines)
> I figured out this morning that my guix pull profile ("current") was more than 1GB. Looking at the closure, I found a few oddities.

Specifically:

Toggle snippet (66 lines)
$ guix describe
Generation 219 Jun 20 2022 09:40:20 (current)
guix 73761d8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 73761d8049f483e6685c2c736872d0366e03238a
$ guix size $(readlink -f ~/.config/guix/current)
store item total self
/gnu/store/rfkyfhdj3zq6lzlw7n0y5m36pdcfd2s7-guix-73761d804-modules 554.6 220.8 27.5%
/gnu/store/249mczqf0jv55a7df9v3a3314mrwjg61-guix-packages-base 123.9 123.9 15.5%
/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8 130.0 53.0 6.6%
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7 129.1 52.0 6.5%
/gnu/store/jv3gkqapz7fxgpjzp7g6rlpfl3fb2pq9-guix-system 51.2 51.2 6.4%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33 38.3 36.6 4.6%
/gnu/store/cwxfvi0890wwmhigk84iiq1dh64x0ac9-guix-packages-base-source 34.2 34.2 4.3%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib 71.7 33.4 4.2%
/gnu/store/3db8s5gn3srsdrzrdz4d0xpxpfhlb3h5-guix-extra 25.7 25.7 3.2%
/gnu/store/bnsf9il448hl5xjavbhq3rcx355svz2v-glib-2.70.2 98.1 15.3 1.9%
/gnu/store/mw3py6smb1pk8yx298hd9ivz9lzbksqi-glibc-utf8-locales-2.33 13.9 13.9 1.7%
/gnu/store/7nlzk7n90ib3llblxlpz725ym3k05gdj-util-linux-2.37.2-lib 80.7 9.0 1.1%
/gnu/store/pyaxxsi4207awhpppqf1br6gl03k47pz-guix-package-cache 6.4 6.4 0.8%
/gnu/store/cyx97f0bx4nki07l52jzw3lng0mzcdcv-guix-cli-core 6.4 6.4 0.8%
/gnu/store/2rdmiv3k11qxz13fjq5bipljwjz0r6ws-guix-manual 6.0 6.0 0.8%
/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619 77.6 5.9 0.7%
/gnu/store/zl9wf0zwq2ka9rpmayp53hnp2mn460xf-gnutls-3.7.2 143.4 5.6 0.7%
/gnu/store/xgp23kc3v9w7l10grjwd0n1a74v3fhx3-openssl-1.1.1n 77.2 5.5 0.7%
/gnu/store/il571kvl9fs08xag4hyg6x8hm57akscm-guile-git-0.5.2 100.5 5.2 0.6%
/gnu/store/dyd5gaxzrngl6m9clniq5y1r7yl463h1-guix-system-tests 4.3 4.3 0.5%
/gnu/store/fg76cjzdk413dfkx50fkcwd3wpbyfpi1-pcre2-10.37 84.6 4.0 0.5%
/gnu/store/ffynx7n76vb5rby4b14yjcacqwq1w70h-mit-krb5-1.19.2 82.2 3.9 0.5%
/gnu/store/v06gnr579r0jmr36aha3wkbd1y27ccg7-disarchive-0.4.0 139.1 3.8 0.5%
/gnu/store/x1jd7pqfn9ilb6x97azcfq1fhjr63p0z-p11-kit-0.23.22 76.4 3.4 0.4%
/gnu/store/xmzx5mzv4863yw9kmr2ykndgp37p8if0-sqlite-3.36.0 82.3 3.2 0.4%
/gnu/store/x1x1sw727g7ls93av3i27mkd90s4wgd7-guix-home 3.2 3.2 0.4%
/gnu/store/jkd4zlfq4rph31xazz132cf0skg6km00-guix-cli 3.1 3.1 0.4%
/gnu/store/v8raqm2shh9azkl71107p53j55hir306-libxcb-1.14 75.3 3.0 0.4%
/gnu/store/ssfq7hv5bhas830cs29fk271brcn3vqi-guile-lib-0.2.7 2.9 2.9 0.4%
/gnu/store/g2ajyl8xk9aarxrgjbng2hkj3qm2v0z2-tar-1.34 75.6 2.9 0.4%
/gnu/store/fa43ijbrb96x08621qigxxiphp503lsi-libx11-1.7.3.1 78.2 2.8 0.4%
/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1 74.4 2.7 0.3%
/gnu/store/yqr33jyy81fdqmr8rd4gvbpisbad2w2l-guix-extra-source 2.5 2.5 0.3%
/gnu/store/4rqq5sl8n85ywfwqdv0f1xjaw9vhgl8k-guix-system-source 2.4 2.4 0.3%
/gnu/store/hkhbq2q1gfs970gsp2nhsmcqb4vmv2xr-libunistring-0.9.10 74.0 2.3 0.3%
/gnu/store/f058zn04xla5jndkhxl0s20pbl61bckq-guile-bytestructures-1.0.10 2.1 2.1 0.3%
/gnu/store/n0sd9hghs18pjsj72023r1spa9wxccc2-libevent-2.1.12 73.8 2.1 0.3%
/gnu/store/m7vwbbsy3pkpi4rpdnvr8m4jc8y36ckn-libgit2-1.3.0 95.4 2.0 0.2%
/gnu/store/xggzgd4xwsy5p02wdfngk67j7zpp91gb-guile-ssh-0.15.1 144.9 1.9 0.2%
/gnu/store/03g49nffc73vrmx5180p4fhr3z4mfk0z-avahi-0.8 111.8 1.7 0.2%
/gnu/store/r08q5kq8hy5621y3yk0c7zrxb9s514z4-guix-locale-guix 1.7 1.7 0.2%
/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8 1.7 1.7 0.2%
/gnu/store/di5bqb45hi5lvp2q08hlxqjdcl9phjb1-pcre-8.45 73.4 1.7 0.2%
/gnu/store/wcwls45278gzpjvwlvrrs1y7h30g44xh-readline-8.1.1 79.0 1.4 0.2%
/gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8 75.1 1.4 0.2%
/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0 76.5 1.4 0.2%
/gnu/store/3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib 72.9 1.2 0.2%
/gnu/store/2b3blhwbag1ial0dhxw7wh4zjxl0cqpk-pkg-config-0.29.2 72.8 1.1 0.1%
/gnu/store/yl859fgb86zgl0zsvbhxdpms945aazip-dbus-1.12.20 79.6 1.1 0.1%
/gnu/store/aggsb6j1svxp70xlll4rqnx5f2pzz794-xz-5.2.5 73.7 1.1 0.1%
/gnu/store/c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5 73.7 1.1 0.1%
[…]
/gnu/store/vjf3hvajws01wmm5rwbkgw7z0jvl6v3h-guix-command 788.6 0.0 0.0%
/gnu/store/hsynjf6csram52x9ampnb90ysdbipdk2-emacs-subdirs 0.0 0.0 0.0%
/gnu/store/yyqqi3kp61r9sjqhhay85in0h5s8dzs8-guix-daemon 789.4 0.0 0.0%
total: 802.0 MiB

50% goes into Guix modules. There’s prolly room for improvement because
the ‘guix-COMMIT-modules’, which is #1, is actually the union of all the
other guix-*-modules.

Toggle quote (2 lines)
> There's gcc in there, which is the second most important contributor after guix-*-modules (150 MB). It's referenced by gcc-toolchain, itself only referenced by the guile-wrapper we build in (guix self). Can we get rid of it?

I think you fixed that one in 319b8331b2357e12ec9edb9665513c32bef56622.
\o/

Toggle quote (2 lines)
> There are three versions of guile (50 MB each). Can we settle for only one?

I think that’s (@ (gnu packages commencement) guile-final), guile-3.0,
and guile-3.0-latest. However I see only two of them here.

Toggle snippet (16 lines)
$ guix graph --path -t references $(readlink -f ~/.config/guix/current) /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8
/gnu/store/njzk97pz238fcjjpjk2vzdv5rgs6s54v-profile
/gnu/store/vp1m80lj2g6391xi95f056yra7xfb47i-guix-73761d804
/gnu/store/vjf3hvajws01wmm5rwbkgw7z0jvl6v3h-guix-command
/gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8
$ guix graph --path -t references $(readlink -f ~/.config/guix/current) /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
/gnu/store/njzk97pz238fcjjpjk2vzdv5rgs6s54v-profile
/gnu/store/vp1m80lj2g6391xi95f056yra7xfb47i-guix-73761d804
/gnu/store/yyqqi3kp61r9sjqhhay85in0h5s8dzs8-guix-daemon
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
$ head -3 /gnu/store/yyqqi3kp61r9sjqhhay85in0h5s8dzs8-guix-daemon
#!/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile --no-auto-compile
!#
(begin (setenv "GUIX" "/gnu/store/vjf3hvajws01wmm5rwbkgw7z0jvl6v3h-guix-command") (unless (getenv "GUIX_STATE_DIRECTORY") (setenv "GUIX_STATE_DIRECTORY" "/var/guix")) (unless (getenv "GUIX_CONFIGURATION_DIRECTORY") (setenv "GUIX_CONFIGURATION_DIRECTORY" "/etc/guix")) (unless (getenv "NIX_STORE_DIR") (setenv "NIX_STORE_DIR" "/gnu/store")) (apply execl "/gnu/store/jmqzsqpgnxrvzpdyx4dglvz9f40b81xm-guix-daemon-1.3.0-27.598f728/bin/guix-daemon" "guix-daemon" (cdr (command-line))))

Fixed this one in commit d418031a8cbdea4e2bc5c52ea1b29ad369579bae.

But then, ‘guile-3.0’ being the default, it’s used in a number of
places, like:

Toggle snippet (8 lines)
$ guix graph -t references --path /gnu/store/6f58rzr1xi8h43l6l8gsm4paravqnnjz-guix-20220626.13 /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
/gnu/store/6f58rzr1xi8h43l6l8gsm4paravqnnjz-guix-20220626.13
/gnu/store/00kkky8qxa73qv8g8y60y5gjz0l4hpmk-guix-command
/gnu/store/m3pdqa0crnvblllvkdjbda42k0rwxn9c-guix-module-union
/gnu/store/v06gnr579r0jmr36aha3wkbd1y27ccg7-disarchive-0.4.0
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7

I can’t think of a good solution to this.

Toggle quote (6 lines)
> Then maybe less important because they're small:
>
> There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and libunistring.
>
> We have bash-minimal and bash-static. The latter is a bit bigger than the former. Maybe we can keep only bash-minimal?

That’s probably due to the fact that there are multiple Guile variants;
annoying.

It’s worth keeping in mind that thanks to deduplication, this costs much
less than it seems in terms of disk space, but it does cost in terms of
bandwidth usage.

Thanks,
Ludo’.
M
M
Maxime Devos wrote on 21 Jul 2022 16:52
d644f79a-f0e3-6166-23cc-db867577f048@telenet.be
On 17-06-2022 07:48, Julien Lepiller wrote:
Toggle quote (2 lines)
> We have bash-minimal and bash-static. The latter is a bit bigger than
> the former. Maybe we can keep only bash-minimal?
bash-static is used by glibc (for the 'system' function), it's not
something that can simply be replaced with bash-minimal (due to the
cycle bash-minimal -> glibc -> bash-minimal that would result). I do
have a proposal eliminating the bash-static reference though:
* replace the 'system' function from glibc by a variant that accepts
the file name of the shell executable
* Add a macro '#define system ...' that calls this variant and inserts
__guix_bin_sh as the shell executable
* In the build system, look for bin/sh in the inputs.  If it exists,
add -D__guix_bin_sh=/gnu/store/.../bin/sh to
CFLAGS or such.
Greetings,
Maxime
Attachment: file
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
(
(
( wrote on 21 Jul 2022 17:03
CLLFC4MVAX97.3PQ5GEUIKALJW@guix-aspire
On Thu Jul 21, 2022 at 3:52 PM BST, Maxime Devos wrote:
Toggle quote (3 lines)
> * Add a macro '#define system ...' that calls this variant and inserts
> __guix_bin_sh as the shell executable

Would this not violate POSIX? Since, as far as I can see,
does not give the implementation license to implement system(3) as a
macro. We could do

```
int system(const char *command) {
return __guix_run_in_shell(command, __guix_bin_sh);
}
```

though.

-- (
(
(
( wrote on 21 Jul 2022 17:11
CLLFIQ1OG10K.BVBWA00UIAGE@guix-aspire
And considering the definition of system(3) in glibc:

@ sysdeps/posix/system.c (took me way too long to find this; glibc's
source code is a maze ;))
```
#define SHELL_PATH "/bin/sh" /* Path of the shell. */
#define SHELL_NAME "sh" /* Name to give it. */
```

couldn't we just use `-DSHELL_PATH=/gnu/store/...`?

-- (
(
(
( wrote on 21 Jul 2022 17:38
CLLG36H5JM2K.1Y4ZTKZC6W5LN@guix-aspire
On Thu Jul 21, 2022 at 4:03 PM BST, paren--- via Bug reports for GNU Guix wrote:
Toggle quote (1 lines)
> Would this not violate POSIX?
Correction: system(3) is ISO C, not POSIX.

But:

@ C11 7.1.4p1
```
... it is permitted to take the address of a library function even if it
is also defined as a macro ^185 ...

185) This means that an implementation shall provide an actual function
for each library function, even if it also provides a macro for that
function.
```

Note the footnote. So this technically would be a violation of ISO C,
but trivially fixed. Apologies for the noise! (Though the SHELL_PATH
solution still applies, of course.)

-- (
J
J
Julien Lepiller wrote on 21 Jul 2022 17:42
B05AC52A-5396-4D45-8658-2FC26E1349CE@lepiller.eu
We're trying to avoid hard-coding bash-static in glibc, instead letting the build-system fill the value in dependents. So that can't be it, right?

Le 21 juillet 2022 17:11:56 GMT+02:00, "(" <paren@disroot.org> a écrit :
Toggle quote (13 lines)
>
>And considering the definition of system(3) in glibc:
>
>@ sysdeps/posix/system.c (took me way too long to find this; glibc's
>source code is a maze ;))
>```
>#define SHELL_PATH "/bin/sh" /* Path of the shell. */
>#define SHELL_NAME "sh" /* Name to give it. */
>```
>
>couldn't we just use `-DSHELL_PATH=/gnu/store/...`?
>
> -- (
Attachment: file
M
M
Maxime Devos wrote on 21 Jul 2022 17:46
22b12576-51f2-2396-a52c-b6956ecd88b5@telenet.be
On 21-07-2022 17:11, ( wrote:
Toggle quote (1 lines)
> couldn't we just use `-DSHELL_PATH=/gnu/store/...`?
Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But
it's not 'just use -DSHELL_PATH=', we still need to change 'system'
appropriately.
Toggle quote (4 lines)
> Would this not violate POSIX? Since, as far as I can see,
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html>
> does not give the implementation license to implement system(3) as a
> macro.
Probably. But does that really matter?  The standard exists for a
reason, but we aren't aiming for POSIX certifications and it isn't the
law or something ... seems rather inconvenient for development outside a
build environment though, so perhaps SHELL_PATH could somehow fallback
to /bin/sh when outside a build environment.
Toggle quote (6 lines)
> We could do
>
> ```
> int system(const char *command) {
> return __guix_run_in_shell(command, __guix_bin_sh);
> }
Needs a 'static' to avoid multiple definitions on the same thing, but
yes, that would avoid the macro problem (though not sufficient for some
FFI).
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
(
(
( wrote on 21 Jul 2022 17:48
CLLGAKRBGL09.2GOO4NHZ0AE4@guix-aspire
On Thu Jul 21, 2022 at 4:42 PM BST, Julien Lepiller wrote:
Toggle quote (1 lines)
> We're trying to avoid hard-coding bash-static in glibc, instead letting the build-system fill the value in dependents. So that can't be it, right?
How would it be any different from -D__guix_bin_sh=...? That argument
would simply be filled in by the build system.
(
(
( wrote on 21 Jul 2022 17:49
CLLGBK9M3110.2MID4Q9LBQ70N@guix-aspire
On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
Toggle quote (3 lines)
> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But
> it's not 'just use -DSHELL_PATH=', we still need to change 'system'
> appropriately.
Why would we need to change it? The glibc definition already uses that
macro for the shell path, it's just hard-coded to /bin/sh by default.
J
J
Julien Lepiller wrote on 21 Jul 2022 17:52
3D5439F2-F6AE-4F19-9254-16E5BD7440DC@lepiller.eu
I must have misunderstood, I thought you wanted to pass it during the build of glibc.

Le 21 juillet 2022 17:49:36 GMT+02:00, "(" <paren@disroot.org> a écrit :
Toggle quote (6 lines)
>On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But
>> it's not 'just use -DSHELL_PATH=', we still need to change 'system'
>> appropriately.
>Why would we need to change it? The glibc definition already uses that
>macro for the shell path, it's just hard-coded to /bin/sh by default.
Attachment: file
(
(
( wrote on 21 Jul 2022 17:52
CLLGE0NEPTNE.1VLP7UY16V193@guix-aspire
Oh! I understand now! The __guix_bin_sh macro would actually be included
in the expansion, not defined during the glibc build. Sorry (again) for
the noise!

-- (
M
M
Maxime Devos wrote on 21 Jul 2022 17:53
ff0242dc-bd7b-df45-5f92-2e1b83f5cfb1@telenet.be
On 21-07-2022 17:49, ( wrote:
Toggle quote (6 lines)
> On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But
>> it's not 'just use -DSHELL_PATH=', we still need to change 'system'
>> appropriately.
> Why would we need to change it? The glibc definition already uses that
> macro for the shell path, it's just hard-coded to /bin/sh by default.
If we modify the SHELL_PATH to point to
/gnu/store/...-bash-minimal-.../bin/sh, then glibc has a reference to
bash-minimal. But bash-minimal uses glibc, so bash-minimal would have a
reference to glibc. So you would have to end up with a cycle, which is
impossible in Guix.
Greetings,
Maxime.
Attachment: file
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
(
(
( wrote on 21 Jul 2022 18:13
CLLGU659UBKV.2M04RRSCIHKYE@guix-aspire
Okay, another (hopefully more coherent) proposal: Patch in a

```
extern char *__guix_shell_path;
```

And then, we use a linker script to provide the definition of
__guix_shell_path at linking time. (Unfortunately there's no way to do
this with a flag, afaik...)

-- (
M
M
Maxime Devos wrote on 21 Jul 2022 18:22
50ad6b55-fb2f-8d24-312d-21655afafe70@telenet.be
On 21-07-2022 18:13, ( wrote:
Toggle quote (9 lines)
> Okay, another (hopefully more coherent) proposal: Patch in a
>
> ```
> extern char *__guix_shell_path;
> ```
>
> And then, we use a linker script to provide the definition of
> __guix_shell_path at linking time. (Unfortunately there's no way to do
> this with a flag, afaik...)
We could compile a '__guix_shell_path = "/..."' during the compilation
of the package (as a .o) and wrap gcc to insert it to the CLI arguments,
no linker scripts required.  Not all linkers support linker scripts,
e.g. mold doesn't from what I've read because they make the linker slower.
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
(
(
( wrote on 21 Jul 2022 18:29
CLLH69CDKUHW.3HK1NCV0BEFFT@guix-aspire
Toggle quote (3 lines)
> We could compile a '__guix_shell_path = "/..."' during the compilation
> of the package (as a .o) and wrap gcc to insert it to the CLI arguments,
> no linker scripts required.
Alas, for some reason I couldn't find any documentation on how to define
strings in a linker script. But never mind that, since that's a far
better idea :)

Toggle quote (2 lines)
> Not all linkers support linker scripts, e.g. mold doesn't from what I've
> read because they make the linker slower.
Would we really need to support anything other than ld, gold, and lld,
though?

-- (
M
M
Maxime Devos wrote on 21 Jul 2022 18:35
c749a063-4a9e-b885-063a-93f941a5572f@telenet.be
On 21-07-2022 18:29, ( wrote:
Toggle quote (6 lines)
>> Not all linkers support linker scripts, e.g. mold doesn't from what I've
>> read because they make the linker slower.
> Would we really need to support anything other than ld, gold, and lld,
> though?
>
> -- (
We can choose to not package mold of course, but I think it would be a
good idea to support mold, because it appears to be much faster than the
others. Furthermore, I'd like to eventually switch to mold by default,
because it's much faster.  From the README:
mold is so fast that it is only 2x /slower/ than |cp| on the same
machine. Feel free to file a bug https://github.com/rui314/mold/issues
if you find mold is not faster than other linkers.
Program (linker output size) GNU gold LLVM lld mold
Chrome 96 (1.89 GiB) 53.86s 11.74s 2.21s
Clang 13 (3.18 GiB) 64.12s 5.82s 2.90s
Firefox 89 libxul (1.64 GiB) 32.95s 6.80s 1.42s
Attachment: file
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
B
B
bokr wrote on 7 Aug 2022 01:37
(name . ()(address . paren@disroot.org)
20220806233726.GA18362@LionPure
Hi "(" aka paren :)

On +2022-07-21 16:03:19 +0100, paren--- via Bug reports for GNU Guix wrote:
[ ... ]
Toggle quote (3 lines)
>
> -- (
>
Are you hoping for some effect on a pre-rfc2822 parser??

Just curious :)
--
Regards,
Bengt Richter
Z
Z
zimoun wrote on 30 Aug 2022 12:04
Re: bug#56030: The guix pull profile is too big
(address . 56030@debbugs.gnu.org)
86o7w2cajh.fsf@gmail.com
Hi,

On Sun, 26 Jun 2022 at 23:20, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (6 lines)
>> There are two libffi, gzip, zlib, libgc, bash-minimal, xz, pkg-config and libunistring.

> It’s worth keeping in mind that thanks to deduplication, this costs much
> less than it seems in terms of disk space, but it does cost in terms of
> bandwidth usage.

As shown in [1], note that deduplication is defeated by packages with
multi-outputs impacted by grafted ones. For example, if one dependency
of bash-minimal is grafted, then two store items of bash-minimal (with
the same content) could live in the store and thus the reduction cost of
disk space is mitigated.



Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 56030@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56030
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch