Conversation
When booting with --stage0-image, mirror ports can change between runs (e.g. file:// -> transient SimpleMirror port), but the reused image kept stale MIRRORS/MIRRORS_LEN values in /steps/bootstrap.cfg. Update stage0-work image preparation to patch bootstrap.cfg on each run: - rewrite MIRRORS and MIRRORS_LEN from current CLI mirrors - keep existing --build-guix-also handoff checks/sync behavior This fixes guest downloads trying old 10.0.2.2:<stale-port> endpoints during steps-guix builds.
…stsuite argp-standalone pass1 builds in a separate build directory. Its testsuite compiles sources that include <argp.h>, but without an explicit include path the header in the source root is not found and build fails. Set: - CPPFLAGS=-I/Users/luoyanpan/CLionProjects/guix/live-bootstrap/.. in src_configure so testsuite objects can resolve argp.h during the normal phase.
…olchain instead of relying on make install
…generation and fts/argp env wiring
…al LIBS and setting host/build + kernel-toolchain env
…ied sha256 and wire it before elfutils
…hs, and disable unused-but-set-variable as error
…compress, and debuginfod client
…mpile via rpath-link and explicit LIBS
feat(steps-guix): add libgcrypt-1.12.1 default build with gcc-detected host and pkg-config path feat(steps-guix): add guile-gcrypt-0.5.0 with dynamic libgcrypt prefix and ld library path
…and end with shared after
… out-of-tree build
…IR for libgcrypt lookup
it's likely still a bootstrap Guile issue? Is this a problem caused by using i686-linux bootstrap guix on guix x86_64-linux target? |
|
i686-linux Guile is correct for bootstrapping x86_64 Guix - the bootstrap sequence includes an explicit cross-compiler step to move from i686 to x86_64. IMO it's more likely to be either a musl vs. glibc issue, or something caused by our too-new GCC (the original bootstrap-guile was built using GCC 4.7 or 4.8 - it's not entirely clear; both versions are referenced in the binary). One option would be to build native coreutils & compression tools earlier (maybe also a real Bash), as that not only takes responsibilities off of bootstrap-guile, avoiding future issues like this, but it would also greatly speed up the build, as most of the time is currently spent starting up instances of bootstrap-guile for each invocation of "test" in shell scripts. (Coreutils "test" is 100x faster on my bootstrap rig than its gash-utils reimplementation, and the real Bash has a built-in "test" command which is 100x faster than coreutils, making "test" operations effectively instantaneous.) |
|
You're absolutely right. However, my question is, when using the official Guix image, running the same command doesn't seem to cause any issues. Is this really a problem with glibc and musl? If that's the case, I think we need evidence to prove that this bug is caused by differences in libc, or we just give it a try, build a glibc for guile and its dependencies, if that solve problem, then it prove that it's because of the libc difference But I should also mention that I encountered the same issue when I compiled Guile using glibc by hand last time, uses a 64-bit toolchain, glibc 2.34, and guile 2.2, idk if I change to a older glibc and 32-bit toolchain can solve the problem The complete log from that time: guix-pull-2.log.txt.zip So, The current evidence does not support the idea that the behavioral differences are caused by libc variations. It might be due to GCC, since I was also using a very recent version of GCC at the time, which is GCC 13. I'd still like to know exactly how to solve this problem And also, based on the guix code, it actually use different guile version for The hash values are different. When I run It is worth noting that this package is not downloaded directly from a remote server; instead, after downloading and extracting it, it is repackaged using an existing EDIT: I'm trying out xz 5.0.6 to see if it solves the problem. |
…e xz 5.0.6, just give it a try to solve problem
|
32- vs 64-bit bootstrap-guile could be relevant as well, indeed. Meanwhile, I've managed to get all the way to gcc-cross-boot0 (so far, build still ongoing) with this patch applied to Guix: As a nice side effect, it also makes builds much faster once the new native binaries are built and used. EDIT: I had to unmount /tmp earlier, as it filled up the RAM on my bootstrap machine during one of the gcc builds. |
|
When building the final gawk in the bootstrap, I encountered this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51286 Seems to be a known, sporadic issue. As expected, fixed on a 2nd try. Suggestion: patch https://codeberg.org/guix/guix/src/tag/v1.5.0/gnu/packages/commencement.scm#L3573 to disable tests. |
|
Got through the bootstrap proper (had to restart once because one of guile-3.0.9's checks locked up - AFAIK this is a known sporadic issue, I seem to remember seeing it before when trying to bootstrap Guix on various platforms), but then immediately after "Computing Guix derivation", as it tries to switch from the "installed" Guix to the one in local-channels, it dies with the familiar system() "No such file or directory" error. The fix is simple: apply remove-environment-variables-system-call.patch also in guix-daemon-and-pull.sh. With that fixed, the build is now proceeding agian. |
|
One more thing: you may want to pass |
So, has this issue been resolved or not? |
|
Resolved, yes. Now, there's a new issue: one of the tests for util-linux, related to user namespace handling, is failing. The cause: CONFIG_USER_NS disabled in the kernel configuration. I'm gonna set it to Y, and try again. |
…ing, readablity improvements(src_dir -> channel_repo)
|
With CONFIG_USER_NS=y in kconfig, util-linux's tests now pass, and Guix moves on to building Valgrind. |
Wait, what stage are you at right now? Are you on |
|
|
|
Ran into and debugged another issue: when building guix-manual, I get the following error: The cause: when this call is executed, However, Fix, option 1: in Fix, option 2: Use a clone or snapshot of the Guix Git repository, rather than a release tarball intended for human use, to prepare the local channel. (Preferably I would also switch the actual build of the Guix package to be based on a Git repository, although live-bootstrap has a preference for release tarballs.) For now, I have locally implemented option 1, and |
|
Successful guix pull - moving on to ISO build. EDIT: "disable-authentication: unrecognized option" - See Googulator/guix@ca0114e for a workaround; unfortunately this causes it to rerun the entire bootstrap :( |
|
Before the ISO build, one also needs to |
just to make sure, what I need to do is add this before iso build in |
3 participants
No description provided.