GNU bug report logs -
#56030
The guix pull profile is too big
Previous Next
To reply to this bug, email your comments to 56030 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Fri, 17 Jun 2022 05:50:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Julien Lepiller <julien <at> lepiller.eu>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Fri, 17 Jun 2022 05:50:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Sun, 26 Jun 2022 21:21:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 56030 <at> debbugs.gnu.org (full text, mbox):
Hi,
Julien Lepiller <julien <at> lepiller.eu> skribis:
> 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:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---
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.
> 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/
> 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.
--8<---------------cut here---------------start------------->8---
$ 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))))
--8<---------------cut here---------------end--------------->8---
Fixed this one in commit d418031a8cbdea4e2bc5c52ea1b29ad369579bae.
But then, ‘guile-3.0’ being the default, it’s used in a number of
places, like:
--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---
I can’t think of a good solution to this.
> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 14:53:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 17-06-2022 07:48, Julien Lepiller wrote:
> 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
[Message part 2 (text/html, inline)]
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:05:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 56030 <at> debbugs.gnu.org (full text, mbox):
On Thu Jul 21, 2022 at 3:52 PM BST, Maxime Devos wrote:
> * 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,
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html>
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.
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:13:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 56030 <at> debbugs.gnu.org (full text, mbox):
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/...`?
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:39:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 56030 <at> debbugs.gnu.org (full text, mbox):
On Thu Jul 21, 2022 at 4:03 PM BST, paren--- via Bug reports for GNU Guix wrote:
> 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.)
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:43:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> disroot.org> a écrit :
>
>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/...`?
>
> -- (
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:47:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 21-07-2022 17:11, ( wrote:
> 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.
> 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.
> 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.
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:49:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 56030 <at> debbugs.gnu.org (full text, mbox):
On Thu Jul 21, 2022 at 4:42 PM BST, Julien Lepiller wrote:
> 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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:50:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 56030 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:53:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> disroot.org> a écrit :
>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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:53:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 56030 <at> debbugs.gnu.org (full text, mbox):
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!
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 15:54:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 21-07-2022 17:49, ( wrote:
> 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.
[Message part 2 (text/html, inline)]
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 16:17:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 56030 <at> debbugs.gnu.org (full text, mbox):
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...)
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 16:24:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 21-07-2022 18:13, ( wrote:
> 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.
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 16:31:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 56030 <at> debbugs.gnu.org (full text, mbox):
> 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 :)
> 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?
-- (
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Thu, 21 Jul 2022 16:36:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 56030 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 21-07-2022 18:29, ( wrote:
>> 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
[Message part 2 (text/html, inline)]
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Sat, 06 Aug 2022 23:38:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 56030 <at> debbugs.gnu.org (full text, mbox):
Hi "(" aka paren :)
On +2022-07-21 16:03:19 +0100, paren--- via Bug reports for GNU Guix wrote:
[ ... ]
>
> -- (
>
Are you hoping for some effect on a pre-rfc2822 parser??
Just curious :)
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#56030; Package
guix.
(Tue, 30 Aug 2022 10:06:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 56030 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Sun, 26 Jun 2022 at 23:20, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> 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.
1: <https://yhetil.org/guix/874jy87gcl.fsf <at> gmail.com>
Cheers,
simon
This bug report was last modified 2 years and 291 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.