Hi! Jan Nieuwenhuizen <jann...@gnu.org> skribis:
> Ludovic Courtès writes: > > Hi! > >> I can see two solutions: >> >> 1. Remove bzip2 support from bootar (it’s not actually needed, is it?). > > Ugly but easiest fix for me, see attached. > >> 2. Modify (compression bzip2) so that it errors out on first use >> rather than at load time. > > Or > 3. Port bzip2 to to 32bit. Indeed! > I would prefer 3., with the fix going upstream. This opens the path to > really using bzip2 in the bootstrap. 2. could be a nice intermediate > step, but I would not know how to do that nicely, as we fetch > (compression bzip2) from upstream. Timothy? I don’t think we’ll introduce new uses of bzip2 on the bootstrap path. So if it’s unnecessary today, it may remain unnecessary in the foreseeable future. > From 06bc492cdc1f476f0caa558546290ceafde357b1 Mon Sep 17 00:00:00 2001 > From: Jan Nieuwenhuizen <jann...@gnu.org> > Date: Fri, 21 Feb 2020 07:46:16 +0100 > Subject: [PATCH] gnu: commencement: bootar: Build fix for i686-linux. > > See #39699 Nitpick: “Fixes <https://bugs.gnu.org/39699>.” :-) > * gnu/packages/commencement.scm (bootar)[i686-linux]: Stub bzip2. [...] > (chdir "bootar") > + (when ,(equal? (%current-system) "i686-linux") > + (delete-file "scripts/bzip2.in") > + (delete-file "compression/bzip2.scm") > + (with-output-to-file "compression/bzip2.scm" > + (lambda _ > + (display "(define-module (compression bzip2)) > +(define-public is-bzip2-file? (const #f)) > +(define-public make-bzip2-input-port (const #f)) > +")))) Perhaps you can write it in a way that avoids rebuilds on x86_64: ,@(if (equal? …) '((…)) '()) Or actually, we can just remove the functionality unconditionally for now since it could be error-prone to have different features depending on the platform. WDYT? Timothy Sample <samp...@ngyro.com> skribis: > Both of those are good options. The 32-bit fixnum limit is a something > of a development artifact. I think I can remove it without problems. > If not, I will just remove BZip2 support for now, since I think you’re > right that we don’t use it. For now I guess we can apply something as discussed above, but in the longer run, it’d be nice to have that 32-bit limit waived! > Sorry for the little hiccup! No problem, it’s really great that we got these binary seeds further reduced! Ludo’.
