GNU bug report logs -
#74217
Bootstrapping Zig with no Binary Blobs
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74217 in the body.
You can then email your comments to 74217 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#74217; Package
guix.
(Tue, 05 Nov 2024 21:49:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ekaitz Zarraga <ekaitz <at> elenq.tech>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Tue, 05 Nov 2024 21:49:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
In order to include modern versions of Zig (Zig 0.12+) in Guix, we need
to remove the binary blobs.
I open this issue to track this effort and store information about the
process.
Some Guix user is trying to achieve the same goal:
https://git.jakstys.lt/motiejus/zig-repro
And discussing about it here:
https://ziggit.dev/t/building-self-hosted-from-the-original-c-implementation/6607/11
We could use that effort as a reference and package it to Guix.
Owner recorded as Ekaitz Zarraga <ekaitz <at> elenq.tech>.
Request was from
Ekaitz Zarraga <ekaitz <at> elenq.tech>
to
control <at> debbugs.gnu.org.
(Tue, 05 Nov 2024 22:06:01 GMT)
Full text and
rfc822 format available.
Added indication that bug 74217 blocks72386
Request was from
Ekaitz Zarraga <ekaitz <at> elenq.tech>
to
control <at> debbugs.gnu.org.
(Tue, 05 Nov 2024 22:06:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 07 Nov 2024 01:26:01 GMT)
Full text and
rfc822 format available.
Message #12 received at 74217 <at> debbugs.gnu.org (full text, mbox):
Hi Ekaitz,
On Wed, 06 Nov 2024 05:47:48 +0800,
Ekaitz Zarraga wrote:
>
> Hi,
>
> In order to include modern versions of Zig (Zig 0.12+) in Guix, we need to
> remove the binary blobs.
>
> I open this issue to track this effort and store information about the process.
>
> Some Guix user is trying to achieve the same goal:
>
> https://git.jakstys.lt/motiejus/zig-repro
>
> And discussing about it here:
>
> https://ziggit.dev/t/building-self-hosted-from-the-original-c-implementation/6607/11
Great news, thanks for sharing!
> We could use that effort as a reference and package it to Guix.
Excited to know Zig developers are willing to help with bootstrapping! We
shouldn't miss this chance :)
I'll look into replicating the current progress this weekend. Anyone reading
this mail wants to join in?
Thanks
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 07 Nov 2024 22:06:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 74217 <at> debbugs.gnu.org (full text, mbox):
>Excited to know Zig developers are willing to help with bootstrapping! We
>shouldn't miss this chance :)
>
>I'll look into replicating the current progress this weekend. Anyone reading
>this mail wants to join in?
Hey Hilton and Ekaitz,
I’m interested in this :) From what I can see the current effort in the
zig-repro repository is very well made and we should just need to
replicate each step with the correct dependencies, hoping they exist 🤞
I can try to make the first few steps as packages tomorrow, WDYT?
Good evening,
Noé
Information forwarded
to
bug-guix <at> gnu.org:
bug#74217; Package
guix.
(Thu, 07 Nov 2024 22:10:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 74217 <at> debbugs.gnu.org (full text, mbox):
Hi
> I can try to make the first few steps as packages tomorrow, WDYT?
Sure!
Send the patches to this issue and I'll review when I have time.
Thanks for the energy!
Information forwarded
to
ekaitz <at> elenq.tech, hako <at> ultrarare.space, noe <at> xn--no-cja.eu, bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 08 Nov 2024 17:45:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 74217 <at> debbugs.gnu.org (full text, mbox):
Finished step 00 from Motiejus Jakštys's script[1], this should make later
work on Guix side easier.
[1]: https://git.jakstys.lt/motiejus/zig-repro/src/branch/main/run
Hilton Chain (2):
gnu: Add zig-0.10.0-610-bootstrap.
gnu: Add zig-0.10.0-610.
gnu/local.mk | 1 +
...10.0-610-bootstrap-resolve-conflicts.patch | 87 ++++++++++
gnu/packages/zig.scm | 151 +++++++++++++++++-
3 files changed, 238 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch
base-commit: 2a6d96425eea57dc6dd48a2bec16743046e32e06
--
2.46.0
Information forwarded
to
ekaitz <at> elenq.tech, hako <at> ultrarare.space, noe <at> xn--no-cja.eu, bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 08 Nov 2024 17:45:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 74217 <at> debbugs.gnu.org (full text, mbox):
* gnu/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch: New
file.
* gnu/local.mk (dist_patch_DATA): Regisiter it.
* gnu/packages/zig.scm (zig-0.10.0-538-source,zig-0.10.0-539-patch)
(zig-0.10.0-542-patch,zig-0.10.0-610-bootstrap): New variables.
Change-Id: I132bbad34f40b919b4573e02d0f40eb4a007a26c
---
gnu/local.mk | 1 +
...10.0-610-bootstrap-resolve-conflicts.patch | 87 +++++++++++++++
gnu/packages/zig.scm | 105 +++++++++++++++++-
3 files changed, 192 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index ae902a5ab2..2cc2ea4c81 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -2358,6 +2358,7 @@ dist_patch_DATA = \
%D%/packages/patches/xygrib-newer-proj.patch \
%D%/packages/patches/yggdrasil-extra-config.patch \
%D%/packages/patches/zig-0.9-riscv-support.patch \
+ %D%/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch \
%D%/packages/patches/zig-use-baseline-cpu-by-default.patch \
%D%/packages/patches/zig-use-system-paths.patch \
%D%/packages/patches/zsh-egrep-failing-test.patch \
diff --git a/gnu/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch b/gnu/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch
new file mode 100644
index 0000000000..5ad5ffc249
--- /dev/null
+++ b/gnu/packages/patches/zig-0.10.0-610-bootstrap-resolve-conflicts.patch
@@ -0,0 +1,87 @@
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 1c03faf1e9..89406eb1b2 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -846,16 +846,17 @@ else()
+ endif()
+
+ set(ZIG_BUILD_ARGS
+- --zig-lib-dir "${CMAKE_SOURCE_DIR}/lib"
+- "-Dconfig_h=${ZIG_CONFIG_H_OUT}"
+- "-Denable-llvm"
+- ${ZIG_RELEASE_ARG}
+- ${ZIG_STATIC_ARG}
+- ${ZIG_NO_LIB_ARG}
+- ${ZIG_SINGLE_THREADED_ARG}
+- "-Dtarget=${ZIG_TARGET_TRIPLE}"
+- "-Dcpu=${ZIG_TARGET_MCPU}"
+- "-Dversion-string=${RESOLVED_ZIG_VERSION}"
++ --zig-lib-dir "${CMAKE_SOURCE_DIR}/lib"
++ "-Dconfig_h=${ZIG_CONFIG_H_OUT}"
++ "-Denable-llvm"
++ "-Denable-stage1"
++ ${ZIG_RELEASE_ARG}
++ ${ZIG_STATIC_ARG}
++ ${ZIG_NO_LIB_ARG}
++ ${ZIG_SINGLE_THREADED_ARG}
++ "-Dtarget=${ZIG_TARGET_TRIPLE}"
++ "-Dcpu=${ZIG_TARGET_MCPU}"
++ "-Dversion-string=${RESOLVED_ZIG_VERSION}"
+ )
+
+ add_custom_target(stage3 ALL
+diff --git a/build.zig b/build.zig
+index cf0e092326..7f80c3e1df 100644
+--- a/build.zig
++++ b/build.zig
+@@ -142,7 +142,8 @@ pub fn build(b: *Builder) !void {
+ const force_gpa = b.option(bool, "force-gpa", "Force the compiler to use GeneralPurposeAllocator") orelse false;
+ const link_libc = b.option(bool, "force-link-libc", "Force self-hosted compiler to link libc") orelse (enable_llvm or only_c);
+ const sanitize_thread = b.option(bool, "sanitize-thread", "Enable thread-sanitization") orelse false;
+- const strip = b.option(bool, "strip", "Omit debug information");
++ const strip = b.option(bool, "strip", "Omit debug information") orelse false;
++ const use_zig0 = b.option(bool, "zig0", "Bootstrap using zig0") orelse false;
+ const value_tracing = b.option(bool, "value-tracing", "Enable extra state tracking to help troubleshoot bugs in the compiler (using the std.debug.Trace API)") orelse false;
+
+ const mem_leak_frames: u32 = b.option(u32, "mem-leak-frames", "How many stack frames to print when a memory leak occurs. Tests get 2x this amount.") orelse blk: {
+@@ -151,7 +152,22 @@ pub fn build(b: *Builder) !void {
+ break :blk 4;
+ };
+
+- const exe = addCompilerStep(b);
++ if (only_c) {
++ target.ofmt = .c;
++ }
++
++ const main_file: ?[]const u8 = mf: {
++ if (!have_stage1) break :mf "src/main.zig";
++ if (use_zig0) break :mf null;
++ break :mf "src/stage1.zig";
++ };
++
++ const exe = b.addExecutable("zig", main_file);
++
++ const compile_step = b.step("compile", "Build the self-hosted compiler");
++ compile_step.dependOn(&exe.step);
++
++ exe.stack_size = stack_size;
+ exe.strip = strip;
+ exe.sanitize_thread = sanitize_thread;
+ exe.build_id = b.option(bool, "build-id", "Include a build id note") orelse false;
+diff --git a/src/translate_c/ast.zig b/src/translate_c/ast.zig
+index 20e4259725..bc0f002c21 100644
+--- a/src/translate_c/ast.zig
++++ b/src/translate_c/ast.zig
+@@ -1448,6 +1448,12 @@ fn renderNode(c: *Context, node: Node) Allocator.Error!NodeIndex {
+ .optional_type => return renderPrefixOp(c, node, .optional_type, .question_mark, "?"),
+ .address_of => {
+ const payload = node.castTag(.address_of).?.data;
++ if (c.zig_is_stage1 and payload.tag() == .fn_identifier)
++ return try c.addNode(.{
++ .tag = .identifier,
++ .main_token = try c.addIdentifier(payload.castTag(.fn_identifier).?.data),
++ .data = undefined,
++ });
+
+ const ampersand = try c.addToken(.ampersand, "&");
+ const base = if (payload.tag() == .fn_identifier)
diff --git a/gnu/packages/zig.scm b/gnu/packages/zig.scm
index 6994d48818..68907fd04e 100644
--- a/gnu/packages/zig.scm
+++ b/gnu/packages/zig.scm
@@ -23,13 +23,15 @@ (define-module (gnu packages zig)
#:use-module (guix gexp)
#:use-module (guix packages)
#:use-module (guix utils)
+ #:use-module (guix download)
#:use-module (guix git-download)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix build-system cmake)
#:use-module (gnu packages)
#:use-module (gnu packages compression)
#:use-module (gnu packages llvm)
- #:use-module (gnu packages llvm-meta))
+ #:use-module (gnu packages llvm-meta)
+ #:use-module (gnu packages web))
(define-public zig-0.9
(package
@@ -196,4 +198,105 @@ (define-public zig-0.10
(properties `((max-silent-time . 9600)
,@(clang-compiler-cpu-architectures "15")))))
+(define zig-0.10.0-538-source
+ ;; "std: added eql to DynamicBitSet and DynamicBitSetUnmanaged"
+ (let ((commit "bf316e550671cc71eb498b3cf799493627bb0fdc")
+ (revision "538"))
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/ziglang/zig")
+ (commit commit)))
+ (file-name (git-file-name "zig" (git-version "0.10" revision commit)))
+ (sha256
+ (base32 "1dchc2bp842jlw0byssqzindv8cigpqcj2hk3752667jrrww13vv")))))
+
+(define zig-0.10.0-539-patch
+ ;; "remove `-fstage1` option"
+ (let ((commit "28514476ef8c824c3d189d98f23d0f8d23e496ea"))
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "https://github.com/ziglang/zig/commit/" commit ".patch"))
+ (sha256
+ (base32 "0qxxiafg2sd5rr4xhw0c12rygd7zh1rmf3x8hfialyxmsbi5pfxp")))))
+
+(define zig-0.10.0-542-patch
+ ;; "actually remove stage1"
+ (let ((commit "3ba916584db5485c38ebf2390e8d22bc6d81bf8e"))
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "https://github.com/ziglang/zig/commit/" commit ".patch"))
+ (sha256
+ (base32 "1l09gmbr3vqzinb63kvaskgs1d0mvm1m7w3ai3ngwg5zlabyya35")))))
+
+;; Build zig1.wasm from source.
+(define zig-0.10.0-610-bootstrap
+ (let ((commit "e7d28344fa3ee81d6ad7ca5ce1f83d50d8502118")
+ (revision "610"))
+ (package
+ (inherit zig-0.10)
+ (name "zig")
+ (version (git-version "0.10.0" revision commit))
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/ziglang/zig")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (modules '((guix build utils)))
+ (snippet '(delete-file "stage1/zig1.wasm.zst"))
+ (sha256
+ (base32
+ "08pm3f4hh6djl3szhqgm7fa3qisdl2xh9jrp18m0z7bk2vd0bzw7"))))
+ (arguments
+ (substitute-keyword-arguments (package-arguments zig-0.10)
+ ((#:phases phases '%standard-phases)
+ #~(modify-phases #$phases
+ (add-after 'unpack 'prepare-source
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+ (copy-recursively "." "../source-backup")
+ ;; Revert "actually remove stage1".
+ (invoke "patch" "--reverse" "--strip=1"
+ "--input" #+zig-0.10.0-542-patch)
+ ;; Revert "remove `-fstage1` option".
+ (false-if-exception
+ (invoke "patch" "--reverse" "--strip=1"
+ "--input" #+zig-0.10.0-539-patch))
+ ;; Resolve conflicts in previous patching.
+ (invoke
+ "patch" "--forward" "--strip=1" "--input"
+ #+(local-file
+ (search-patch
+ "zig-0.10.0-610-bootstrap-resolve-conflicts.patch")))
+ ;; Restore build system.
+ (rename-file "stage1/config.zig.in" "src/config.zig.in")
+ (substitute* "src/config.zig.in"
+ (("(have_stage1 = )false" _ prefix)
+ (string-append prefix "true")))
+ (for-each
+ (lambda (file)
+ (copy-file (string-append #+zig-0.10.0-538-source "/" file)
+ file))
+ '("build.zig" "CMakeLists.txt"))))
+ (add-after 'install 'build-zig1
+ (lambda _
+ (copy-recursively "../source-backup" ".")
+ (invoke (string-append #$output "/bin/zig")
+ "build" "update-zig1" "--verbose")))
+ (add-after 'build-zig1 'install-zig1
+ (lambda _
+ (install-file "stage1/zig1.wasm.zst"
+ (string-append #$output:zig1 "/bin"))))
+ (replace 'check
+ (lambda* (#:key tests? #:allow-other-keys)
+ (when tests?
+ (invoke (string-append #$output "/bin/zig")
+ "test" "-I" "test" "test/behavior.zig"))))))))
+ (native-inputs
+ (modify-inputs (package-native-inputs zig-0.10)
+ (prepend binaryen)))
+ (outputs '("out" "zig1")))))
+
(define-public zig zig-0.10)
--
2.46.0
Information forwarded
to
ekaitz <at> elenq.tech, hako <at> ultrarare.space, noe <at> xn--no-cja.eu, bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 08 Nov 2024 17:45:03 GMT)
Full text and
rfc822 format available.
Message #27 received at 74217 <at> debbugs.gnu.org (full text, mbox):
* gnu/packages/zig.scm (zig-0.10.0-610): New variable.
Change-Id: I277a7f5e9781e89d7ad7cd108fec9afcf8cd23d9
---
gnu/packages/zig.scm | 46 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/gnu/packages/zig.scm b/gnu/packages/zig.scm
index 68907fd04e..4174dba38b 100644
--- a/gnu/packages/zig.scm
+++ b/gnu/packages/zig.scm
@@ -299,4 +299,50 @@ (define zig-0.10.0-610-bootstrap
(prepend binaryen)))
(outputs '("out" "zig1")))))
+;; Bootstrap with our zig1.wasm.
+(define zig-0.10.0-610
+ (let ((commit "e7d28344fa3ee81d6ad7ca5ce1f83d50d8502118")
+ (revision "610"))
+ (package
+ (inherit zig-0.10)
+ (name "zig")
+ (version (git-version "0.10.0" revision commit))
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/ziglang/zig")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (modules '((guix build utils)))
+ (snippet '(delete-file "stage1/zig1.wasm.zst"))
+ (sha256
+ (base32
+ "08pm3f4hh6djl3szhqgm7fa3qisdl2xh9jrp18m0z7bk2vd0bzw7"))))
+ (arguments
+ (substitute-keyword-arguments (package-arguments zig-0.10)
+ ((#:phases phases '%standard-phases)
+ #~(modify-phases #$phases
+ (add-after 'unpack 'unpack-zig1
+ (lambda* (#:key native-inputs inputs #:allow-other-keys)
+ (install-file (search-input-file
+ (or native-inputs inputs) "bin/zig1.wasm.zst")
+ "stage1")))
+ (add-after 'install 'update-zig1
+ (lambda _
+ (invoke (string-append #$output "/bin/zig")
+ "build" "update-zig1" "--verbose")))
+ (add-after 'update-zig1 'install-zig1
+ (lambda _
+ (install-file "stage1/zig1.wasm.zst"
+ (string-append #$output:zig1 "/bin"))))
+ (replace 'check
+ (lambda* (#:key tests? #:allow-other-keys)
+ (when tests?
+ (invoke (string-append #$output "/bin/zig")
+ "test" "-I" "test" "test/behavior.zig"))))))))
+ (native-inputs
+ (modify-inputs (package-native-inputs zig-0.10)
+ (prepend binaryen `(,zig-0.10.0-610-bootstrap "zig1"))))
+ (outputs '("out" "zig1")))))
+
(define-public zig zig-0.10)
--
2.46.0
Information forwarded
to
ekaitz <at> elenq.tech, noe <at> xn--no-cja.eu, bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 09 Nov 2024 17:27:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 74217 <at> debbugs.gnu.org (full text, mbox):
I have added a wip-zig-bootstrap[1] branch.
Variables are not exported, you can build them locally with the following
command:
--8<---------------cut here---------------start------------->8---
ZIG=$(
sed 's/^\(define(-public)? (zig-.*-.*)/\2/p' gnu/packages/zig.scm \
--quiet --regexp-extended |
tail --lines=1
)
./pre-inst-env guix build --expression="(@@ (gnu packages zig) $ZIG)"
--8<---------------cut here---------------end--------------->8---
Thanks
---
[1]: https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-zig-bootstrap
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Mon, 11 Nov 2024 11:44:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Nov 07, 2024 at 09:19:23AM +0800, Hilton Chain wrote:
> Hi Ekaitz,
>
> On Wed, 06 Nov 2024 05:47:48 +0800,
> Ekaitz Zarraga wrote:
> >
> > Hi,
> >
> > In order to include modern versions of Zig (Zig 0.12+) in Guix, we need to
> > remove the binary blobs.
> >
> > I open this issue to track this effort and store information about the process.
> >
> > Some Guix user is trying to achieve the same goal:
> >
> > https://git.jakstys.lt/motiejus/zig-repro
> >
> > And discussing about it here:
> >
> > https://ziggit.dev/t/building-self-hosted-from-the-original-c-implementation/6607/11
>
>
> Great news, thanks for sharing!
>
>
> > We could use that effort as a reference and package it to Guix.
>
>
> Excited to know Zig developers are willing to help with bootstrapping! We
> shouldn't miss this chance :)
>
> I'll look into replicating the current progress this weekend. Anyone reading
> this mail wants to join in?
Ok, you've convinced me. I guess I finally need to get zig <at> 0.10
building correctly on riscv64.
Expect plenty of FIXUP and SQUASH commits in the future.
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Mon, 11 Nov 2024 11:57:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 74217 <at> debbugs.gnu.org (full text, mbox):
Hi Efraim,
On Mon, 11 Nov 2024 19:42:25 +0800,
Efraim Flashner wrote:
>
> Ok, you've convinced me. I guess I finally need to get zig <at> 0.10
> building correctly on riscv64.
>
> Expect plenty of FIXUP and SQUASH commits in the future.
I have something to fix with a force-push on wip-zig-bootstrap, I'll reply here
when the branch is ready to be worked on :)
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Mon, 11 Nov 2024 12:04:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Nov 11, 2024 at 07:56:30PM +0800, Hilton Chain wrote:
> Hi Efraim,
>
> On Mon, 11 Nov 2024 19:42:25 +0800,
> Efraim Flashner wrote:
> >
> > Ok, you've convinced me. I guess I finally need to get zig <at> 0.10
> > building correctly on riscv64.
> >
> > Expect plenty of FIXUP and SQUASH commits in the future.
>
> I have something to fix with a force-push on wip-zig-bootstrap, I'll reply here
> when the branch is ready to be worked on :)
No worries. I'm still getting a look around the branch. And if you
force-push then my regular push will be rejected and I can rebase
whatever I have.
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Wed, 13 Nov 2024 16:48:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 74217 <at> debbugs.gnu.org (full text, mbox):
Hello everyone,
With a new forced push (and new rebuilds, sorry), wip-zig-bootstrap is mostly
ready (for me) now. Please take a look at the first few commits, as I'm
changing Zig's behavior there, here are some additional notes:
To Efraim: Can adding pkg-config to native-inputs avoid the ncdu snippet?
I'm building this branch on my personal Cuirass instance[1][2], for x86_64-linux
and aarch64-linux (qemu-binfmt), in previous revisions I have indentified
reproduciblity issue, and aarch64 builds timed-out. I haven't investigated them
yet.
Then for what's the RUNPATH issue I have mentioned in commits:
+ For current zig <at> 0.10 on Guix master: glibc is missing from RUNPATH, which
fails the validate-runpath check.
+ For zig <at> 0.11, some other inputs are missing, making the binary failing to run on Guix[3].
+ dan also mentioned privately to me that they needed to add paths from
LIBRARY_PATH to RUNPATH for their own projects, so programs built by Zig is also
affected.
I think this is due to Zig's implemention of its own linking logic, which
bypasses our ld-wrapper.
I'm not going to implement ld-wrapper within Zig. :) So my proposed workaround
in wip-zig-bootstrap is to patch the handling logic added for Guix:
(In lib/std/zig/system/NativePaths.zig)
--8<---------------cut here---------------start------------->8---
// Distros like guix don't use FHS, so they rely on environment
// variables to search for headers and libraries.
// We use os.getenv here since this part won't be executed on
// windows, to get rid of unnecessary error handling.
- if (std.posix.getenv("C_INCLUDE_PATH")) |c_include_path| {
+ if (std.posix.getenv("CROSS_C_INCLUDE_PATH") orelse std.posix.getenv("C_INCLUDE_PATH")) |c_include_path| {
var it = mem.tokenizeScalar(u8, c_include_path, ':');
while (it.next()) |dir| {
try self.addIncludeDir(dir);
}
}
- if (std.posix.getenv("CPLUS_INCLUDE_PATH")) |cplus_include_path| {
+ if (std.posix.getenv("CROSS_CPLUS_INCLUDE_PATH") orelse std.posix.getenv("CPLUS_INCLUDE_PATH")) |cplus_include_path| {
var it = mem.tokenizeScalar(u8, cplus_include_path, ':');
while (it.next()) |dir| {
try self.addIncludeDir(dir);
}
}
- if (std.posix.getenv("LIBRARY_PATH")) |library_path| {
+ if (std.posix.getenv("CROSS_LIBRARY_PATH") orelse std.posix.getenv("LIBRARY_PATH")) |library_path| {
var it = mem.tokenizeScalar(u8, library_path, ':');
while (it.next()) |dir| {
try self.addLibDir(dir);
+ try self.addRPath(dir);
}
}
}
--8<---------------cut here---------------end--------------->8---
Adding directories from CROSS_LIBRARY_PATH or LIBRARY_PATH to RUNPATH, "CROSS_"
part is for our cross toolchain, I haven't tested it yet.
I think this behavior change is reasonable since the search path
(CROSS_)?LIBRARY_PATH is only automatically set by our compilers.
I added this change to 0.9 as well to make all Zigs behave consistently. I also
used shrink-runpath phase from meson-build-system in Zig and zig-build-system.
I want to move shrink-runpath to (guix build utils) and export it too, so that
it can be used easier. But I'm not sure if this change will trigger rebuilds of
other packages, so I didn't do it.
Thanks to Guile, for builds not managed by guix-daemon, something like the
following script can be used, we can ship a program-file if we agree on this
workaround.
--8<---------------cut here---------------start------------->8---
(use-modules (guix build meson-build-system))
(define shrink-runpath
(assoc-ref %standard-phases 'shrink-runpath))
(define (main directories)
(for-each (lambda (dir)
(false-if-exception
(shrink-runpath
#:elf-directories '(".")
#:outputs `(("out" . ,dir)))))
directories))
(main (cdr (command-line)))
--8<---------------cut here---------------end--------------->8---
Usage: guile <file-with-above-content> DIRECTORY...
Thanks
---
[1]: https://ci.boiledscript.com/jobset/guix-zig
[2]: https://substitute.boiledscript.com, if you want to challenge it.
[3]: https://github.com/ziglang/zig/issues/18434
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Wed, 13 Nov 2024 18:12:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Nov 14, 2024 at 12:46:59AM +0800, Hilton Chain wrote:
> Hello everyone,
>
> With a new forced push (and new rebuilds, sorry), wip-zig-bootstrap is mostly
> ready (for me) now. Please take a look at the first few commits, as I'm
> changing Zig's behavior there, here are some additional notes:
>
> To Efraim: Can adding pkg-config to native-inputs avoid the ncdu snippet?
Unfortunately no. The code reads:
exe.root_module.linkSystemLibrary("ncursesw", .{});
exe.root_module.linkSystemLibrary("libzstd", .{});
and so it searches (something like the following, I lost the log):
/usr/lib/liblibzstd.so
/usr/lib/liblibzstd.a
...
/gnu/store/...-glibc.../lib/liblibzstd.so
/gnu/store/...-glibc.../lib/liblibzstd.a
...
/gnu/store/...-zstd.../lib/liblibzstd.so
/gnu/store/...-zstd.../lib/liblibzstd.a
so it looks like it automatically adds the 'lib' at the front. When I've
built out to ncdu again I'll check it again.
> I'm building this branch on my personal Cuirass instance[1][2], for x86_64-linux
> and aarch64-linux (qemu-binfmt), in previous revisions I have indentified
> reproduciblity issue, and aarch64 builds timed-out. I haven't investigated them
> yet.
I've also been having berlin build zig on the wip-zig-bootstrap branch
for x86_64. Unfortunately there's quite a bit to go on aarch64 for it to
get there, but I can confirm from my machine that it's working.
> Then for what's the RUNPATH issue I have mentioned in commits:
> + For current zig <at> 0.10 on Guix master: glibc is missing from RUNPATH, which
> fails the validate-runpath check.
> + For zig <at> 0.11, some other inputs are missing, making the binary failing to run on Guix[3].
> + dan also mentioned privately to me that they needed to add paths from
> LIBRARY_PATH to RUNPATH for their own projects, so programs built by Zig is also
> affected.
I didn't test it. ncdu <at> 2.3 builds with zig-0.11, so that's an option for
testing it out.
https://dev.yorhel.nl/ncdu/changes2
> I think this is due to Zig's implemention of its own linking logic, which
> bypasses our ld-wrapper.
I wonder if switching from lld to make-lld-wrapper would make a
difference here.
> I'm not going to implement ld-wrapper within Zig. :) So my proposed workaround
> in wip-zig-bootstrap is to patch the handling logic added for Guix:
>
> (In lib/std/zig/system/NativePaths.zig)
> --8<---------------cut here---------------start------------->8---
> // Distros like guix don't use FHS, so they rely on environment
> // variables to search for headers and libraries.
> // We use os.getenv here since this part won't be executed on
> // windows, to get rid of unnecessary error handling.
> - if (std.posix.getenv("C_INCLUDE_PATH")) |c_include_path| {
> + if (std.posix.getenv("CROSS_C_INCLUDE_PATH") orelse std.posix.getenv("C_INCLUDE_PATH")) |c_include_path| {
> var it = mem.tokenizeScalar(u8, c_include_path, ':');
> while (it.next()) |dir| {
> try self.addIncludeDir(dir);
> }
> }
>
> - if (std.posix.getenv("CPLUS_INCLUDE_PATH")) |cplus_include_path| {
> + if (std.posix.getenv("CROSS_CPLUS_INCLUDE_PATH") orelse std.posix.getenv("CPLUS_INCLUDE_PATH")) |cplus_include_path| {
> var it = mem.tokenizeScalar(u8, cplus_include_path, ':');
> while (it.next()) |dir| {
> try self.addIncludeDir(dir);
> }
> }
>
> - if (std.posix.getenv("LIBRARY_PATH")) |library_path| {
> + if (std.posix.getenv("CROSS_LIBRARY_PATH") orelse std.posix.getenv("LIBRARY_PATH")) |library_path| {
> var it = mem.tokenizeScalar(u8, library_path, ':');
> while (it.next()) |dir| {
> try self.addLibDir(dir);
> + try self.addRPath(dir);
> }
> }
> }
> --8<---------------cut here---------------end--------------->8---
>
> Adding directories from CROSS_LIBRARY_PATH or LIBRARY_PATH to RUNPATH, "CROSS_"
> part is for our cross toolchain, I haven't tested it yet.
I like this, and it seems like it should make it work for cross
compiling zig programs. That's part of why I added the updated ncdu
commit, to use it for testing.
> I think this behavior change is reasonable since the search path
> (CROSS_)?LIBRARY_PATH is only automatically set by our compilers.
>
> I added this change to 0.9 as well to make all Zigs behave consistently. I also
> used shrink-runpath phase from meson-build-system in Zig and zig-build-system.
>
> I want to move shrink-runpath to (guix build utils) and export it too, so that
> it can be used easier. But I'm not sure if this change will trigger rebuilds of
> other packages, so I didn't do it.
I found that there was still the full LIBRARY_PATH embedded in the ncdu
binary as a string. So with that I'm not sure about using RPath instead
of LibDir for the LIBRARY_PATH.
> Thanks to Guile, for builds not managed by guix-daemon, something like the
> following script can be used, we can ship a program-file if we agree on this
> workaround.
> --8<---------------cut here---------------start------------->8---
> (use-modules (guix build meson-build-system))
>
> (define shrink-runpath
> (assoc-ref %standard-phases 'shrink-runpath))
>
> (define (main directories)
> (for-each (lambda (dir)
> (false-if-exception
> (shrink-runpath
> #:elf-directories '(".")
> #:outputs `(("out" . ,dir)))))
> directories))
>
> (main (cdr (command-line)))
> --8<---------------cut here---------------end--------------->8---
> Usage: guile <file-with-above-content> DIRECTORY...
>
>
> Thanks
> ---
> [1]: https://ci.boiledscript.com/jobset/guix-zig
> [2]: https://substitute.boiledscript.com, if you want to challenge it.
> [3]: https://github.com/ziglang/zig/issues/18434
I spent a bunch of time trying to get zig-0.10 or 0.10.0-610 to build on
riscv64 and ppc64le but haven't been able to crack it yet.
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Wed, 13 Nov 2024 23:41:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Nov 2024 02:10:44 +0800,
Efraim Flashner wrote:
>
> > I think this is due to Zig's implemention of its own linking logic, which
> > bypasses our ld-wrapper.
>
> I wonder if switching from lld to make-lld-wrapper would make a
> difference here.
Thanks for mentioning! This should do the work!
I thought Zig was using lld as a library for linking. Just looked at
src/link/Elf.zig, this is not true, it invokes ld.lld.
I have more time today. I'll test this out and see if lld-as-ld-wrapper can
also add glibc RUNPATH.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 14 Nov 2024 01:07:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Nov 2024 07:40:05 +0800,
Hilton Chain wrote:
>
> On Thu, 14 Nov 2024 02:10:44 +0800,
> Efraim Flashner wrote:
> >
> > > I think this is due to Zig's implemention of its own linking logic, which
> > > bypasses our ld-wrapper.
> >
> > I wonder if switching from lld to make-lld-wrapper would make a
> > difference here.
>
> Thanks for mentioning! This should do the work!
>
> I thought Zig was using lld as a library for linking. Just looked at
> src/link/Elf.zig, this is not true, it invokes ld.lld.
>
> I have more time today. I'll test this out and see if lld-as-ld-wrapper can
> also add glibc RUNPATH.
Zig manages linking to libc seperately, if this approach works, we have to
keep validate-runpath? off for Zig. Reference to ld.lld can't be patched
since it's both native-inputs (for building Zig) and inputs (for using the
built Zig), maybe we can add a zig-toolchain (zig + lld-wrapper) later?
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 14 Nov 2024 06:07:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Nov 2024 09:05:41 +0800,
Hilton Chain wrote:
>
> On Thu, 14 Nov 2024 07:40:05 +0800,
> Hilton Chain wrote:
> >
> > I thought Zig was using lld as a library for linking. Just looked at
> > src/link/Elf.zig, this is not true, it invokes ld.lld.
> >
> > I have more time today. I'll test this out and see if lld-as-ld-wrapper can
> > also add glibc RUNPATH.
>
> Zig manages linking to libc seperately, if this approach works, we have to
> keep validate-runpath? off for Zig. Reference to ld.lld can't be patched
> since it's both native-inputs (for building Zig) and inputs (for using the
> built Zig), maybe we can add a zig-toolchain (zig + lld-wrapper) later?
ld.lld is invoked in 'zig clang' route, sorry for the noise.
Currently I'm 1. modifying each-lib-rpath option of 'zig build'. 2. passing
libc to linker. I'll write details on this when succeed.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 14 Nov 2024 09:23:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Nov 2024 14:05:52 +0800,
Hilton Chain wrote:
>
> Currently I'm 1. modifying each-lib-rpath option of 'zig build'. 2. passing
> libc to linker. I'll write details on this when succeed.
1. Modification about each-lib-rpath.
--8<---------------cut here---------------start------------->8---
-feach-lib-rpath Ensure adding rpath for each used dynamic library
--8<---------------cut here---------------end--------------->8---
This option is on implicitly for native builds. This implicity is what our Zig
currently solely relies on.
I'm modifying it so that it's also on when CROSS_LIBRARY_PATH or LIBRARY_PATH is
set. This approach is better than my previous one since it only adds needed
libraries.
2. Pass libc to Zig's linker
This was the behavior in 0.9, but changed due to issue on macOS[1]. (btw, our
CPLUS_INCLUDE_PATH also has issue with macOS target[2]). RUNPATH for glibc was
missing because of this, since it's the linker handling each-lib-rpath.
Since we do not support macOS anyway, can we restore this behavior?
I also have concern for Zig's relying on /usr/bin/env (Zig uses an ELF file to
find dynamic linker, env is chosen for it's well-known). We have patched this
reference, not sure if it will cause issue for cross-building Zig.
Thanks
---
[1]: https://github.com/ziglang/zig/issues/10765
[2]: https://github.com/ziglang/zig/issues/18063
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 14 Nov 2024 09:43:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Nov 14, 2024 at 05:22:17PM +0800, Hilton Chain wrote:
> On Thu, 14 Nov 2024 14:05:52 +0800,
> Hilton Chain wrote:
> >
> > Currently I'm 1. modifying each-lib-rpath option of 'zig build'. 2. passing
> > libc to linker. I'll write details on this when succeed.
>
> 1. Modification about each-lib-rpath.
> --8<---------------cut here---------------start------------->8---
> -feach-lib-rpath Ensure adding rpath for each used dynamic library
> --8<---------------cut here---------------end--------------->8---
>
> This option is on implicitly for native builds. This implicity is what our Zig
> currently solely relies on.
>
> I'm modifying it so that it's also on when CROSS_LIBRARY_PATH or LIBRARY_PATH is
> set. This approach is better than my previous one since it only adds needed
> libraries.
>
>
> 2. Pass libc to Zig's linker
> This was the behavior in 0.9, but changed due to issue on macOS[1]. (btw, our
> CPLUS_INCLUDE_PATH also has issue with macOS target[2]). RUNPATH for glibc was
> missing because of this, since it's the linker handling each-lib-rpath.
>
> Since we do not support macOS anyway, can we restore this behavior?
At worst I could see adding a comment that it would likely break future
macOS cross-compiles. I don't see an issue with either putting it back
unconditionally or trying to make it conditional based on
(%current-system) or the contents of (%current-target-system).
>
> I also have concern for Zig's relying on /usr/bin/env (Zig uses an ELF file to
> find dynamic linker, env is chosen for it's well-known). We have patched this
> reference, not sure if it will cause issue for cross-building Zig.
We use search-input-file in the replacement, so it should choose the
cross-binutils for the replacement /bin/env, so it shouldn't be a
problem.
>
> Thanks
> ---
> [1]: https://github.com/ziglang/zig/issues/10765
> [2]: https://github.com/ziglang/zig/issues/18063
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 14 Nov 2024 14:35:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, Nov 14, 2024 at 11:22 AM Hilton Chain <hako <at> ultrarare.space> wrote:
>
> On Thu, 14 Nov 2024 14:05:52 +0800,
> Hilton Chain wrote:
> I also have concern for Zig's relying on /usr/bin/env (Zig uses an ELF file to
> find dynamic linker, env is chosen for it's well-known). We have patched this
> reference, not sure if it will cause issue for cross-building Zig.
This file is only consulted when `-target=native`. I.e. when it needs
to compile for the host. If target is specified, it will not consult
that file.
Just verified with zig 0.13.0:
$ strace -f -e openat zig cc hello.c -o hello |& grep -w env
openat(AT_FDCWD,
"/nix/store/sf6y4arqcm100rnnl3dhpg732i774zp6-coreutils-9.5/bin/env",
O_RDONLY|O_NOCTTY|O_CLOEXEC) = 5
$ strace -f -e openat zig cc -target x86_64-linux-gnu.2.32 hello.c -o
hello |& grep -w env
$
Motiejus
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 15 Nov 2024 03:30:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 14 Nov 2024 17:41:04 +0800,
Efraim Flashner wrote:
>
> [1 <text/plain; utf-8 (quoted-printable)>]
> On Thu, Nov 14, 2024 at 05:22:17PM +0800, Hilton Chain wrote:
> > 2. Pass libc to Zig's linker
> > This was the behavior in 0.9, but changed due to issue on macOS[1]. (btw, our
> > CPLUS_INCLUDE_PATH also has issue with macOS target[2]). RUNPATH for glibc was
> > missing because of this, since it's the linker handling each-lib-rpath.
> >
> > Since we do not support macOS anyway, can we restore this behavior?
>
> At worst I could see adding a comment that it would likely break future
> macOS cross-compiles. I don't see an issue with either putting it back
> unconditionally or trying to make it conditional based on
> (%current-system) or the contents of (%current-target-system).
Bad news: Zig 0.12 changed[1] behavior of each_lib_rpath, it won't filter
libraries now.
Good news: Thanks to this diff, I know how to add libc to RUNPATH now :)
Another forced push, I have ensured consistent behavior for
(CROSS_)?LIBRARY_PATH and added libc RUNPATH without restoring the behavior
passing '-lc' to linker.
Who said not going to implement a ld-wrapper within Zig? :P
Fortunately it was already there :)
BTW, adding pkg-config to native-inputs works for ncdu.
> > I also have concern for Zig's relying on /usr/bin/env (Zig uses an ELF file to
> > find dynamic linker, env is chosen for it's well-known). We have patched this
> > reference, not sure if it will cause issue for cross-building Zig.
>
> We use search-input-file in the replacement, so it should choose the
> cross-binutils for the replacement /bin/env, so it shouldn't be a
> problem.
On Thu, 14 Nov 2024 17:47:23 +0800,
Motiejus Jakštys wrote:
>
> This file is only consulted when `-target=native`. I.e. when it needs
> to compile for the host. If target is specified, it will not consult
> that file.
>
> Just verified with zig 0.13.0:
>
> $ strace -f -e openat zig cc hello.c -o hello |& grep -w env
> openat(AT_FDCWD,
> "/nix/store/sf6y4arqcm100rnnl3dhpg732i774zp6-coreutils-9.5/bin/env",
> O_RDONLY|O_NOCTTY|O_CLOEXEC) = 5
> $ strace -f -e openat zig cc -target x86_64-linux-gnu.2.32 hello.c -o
> hello |& grep -w env
> $
Thanks! Then it should be in inputs. I don't want to add coreutils to it, so I
patched reference of /usr/bin/env to clang++ (it's both in inputs and RUNPATH)
instead.
---
[1]: https://github.com/ziglang/zig/commit/852e7e24b5f15b489463bdabb0039e2a424e5ee6
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 15 Nov 2024 14:32:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Fri, 15 Nov 2024 11:29:10 +0800,
Hilton Chain wrote:
>
> Good news: Thanks to this diff, I know how to add libc to RUNPATH now :)
>
> Another forced push, I have ensured consistent behavior for
> (CROSS_)?LIBRARY_PATH and added libc RUNPATH without restoring the behavior
> passing '-lc' to linker.
>
> Who said not going to implement a ld-wrapper within Zig? :P
> Fortunately it was already there :)
>
> BTW, adding pkg-config to native-inputs works for ncdu.
I have locally made the "use-system-paths" patch larger so that Zig can really
honor "CROSS_" environment variables.
The next issue is cross building with pkg-config. Zig only invokes
"pkg-config", but we don't have a "pkg-config" with search path for target
inputs. I can add a pkg-config-for-zig to workaround this, and then... It's
dynamic linker path, I'll look into it soon.
Also for reproducibility, bin/zig is the only file differs and here's the diff,
I don't know about this part so I currently have no idea on fixing it.
--8<---------------cut here---------------start------------->8---
--- /gnu/store/gqdi4drfn3js5cwgfmlpkyfm2xf3l5b0-zig-0.10.1/bin/zig
+++ cuirass/gqdi4drfn3js5cwgfmlpkyfm2xf3l5b0-zig-0.10.1/bin/zig
├── readelf --wide --decompress --string-dump=.rodata {}
│ @@ -77024,14 +77024,16 @@
│ [149be0] +�&
│ [149bf9] )&
│ [149c12] %
│ [149c28] VO$
│ [149c40] D�(
│ [149c59] >$
│ [149c70] 8�%
│ + [149c94] ;
│ + [149ca0] ;
│ [149ca8] '
│ [149cb0] uespemos�odnarodarenegylsetybdet
│ [149cf0] p��
│ [149d11] O'
│ [149d21] 5&
│ [149d31] f&
│ [149d40] SJ'
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
--- /gnu/store/466cm9xpjqg80iqracj4qirsrdha1rnk-zig-0.11.0/bin/zig
+++ cuirass/466cm9xpjqg80iqracj4qirsrdha1rnk-zig-0.11.0/bin/zig
├── readelf --wide --decompress --string-dump=.rodata {}
│ @@ -64905,14 +64905,16 @@
│ [ 5ae48] xpnt4win2kvistawin10ws2003win8_1win10_th2win10_rs1win10_rs2win10_rs3win10_rs4win10_rs5win10_19h1
│ [ 5aef0]
│ [ 5aef8] #
│ [ 5af00] %
│ [ 5af08] %
│ [ 5af10] &
│ [ 5af78] celfhexrawmachospirvdxcontainer
│ + [ 5afc0] ;
│ + [ 5aff8] ;
│ [ 5b070] E
│ [ 5b0b4] ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_
│ [ 5b350]
│ [ 5b380] @
│ [ 5b3e0]
│ [ 5b420] ]
│ [ 5b5e0] %
--8<---------------cut here---------------end--------------->8---
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 16 Nov 2024 06:56:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Fri, 15 Nov 2024 22:30:40 +0800,
Hilton Chain wrote:
>
> I have locally made the "use-system-paths" patch larger so that Zig can really
> honor "CROSS_" environment variables.
>
> The next issue is cross building with pkg-config. Zig only invokes
> "pkg-config", but we don't have a "pkg-config" with search path for target
> inputs. I can add a pkg-config-for-zig to workaround this, and then... It's
> dynamic linker path, I'll look into it soon.
Adding a file with content like the following and passing --libc <this file> to
zig works, RUNPATH is correct and no need to set CC then.
--8<---------------cut here---------------start------------->8---
include_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/include
sys_include_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/include
crt_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/lib
msvc_lib_dir=
kernel32_lib_dir=
gcc_dir=
--8<---------------cut here---------------end--------------->8---
For cross builds interpreter path like /lib/ld-linux-aarch64.so.1 is used in
output binary, I'll find a way to fix it.
> Also for reproducibility, bin/zig is the only file differs and here's the diff,
> I don't know about this part so I currently have no idea on fixing it.
This seem to be an upstream issue, Zig is reproducible only on the same machine.
I'll verify it and report to upstream.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 16 Nov 2024 07:15:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sat, Nov 16, 2024 at 8:55 AM Hilton Chain <hako <at> ultrarare.space> wrote:
>
> On Fri, 15 Nov 2024 22:30:40 +0800,
> Hilton Chain wrote:
> >
> > Also for reproducibility, bin/zig is the only file differs and here's the diff,
> > I don't know about this part so I currently have no idea on fixing it.
>
> This seem to be an upstream issue, Zig is reproducible only on the same machine.
> I'll verify it and report to upstream.
Zig defaults to `-march=native` when building for the host. Try
ZIG_TARGET_MCPU=baseline when building stage3.
Motiejus
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 16 Nov 2024 07:20:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sat, 16 Nov 2024 15:13:40 +0800,
Motiejus Jakštys wrote:
>
> On Sat, Nov 16, 2024 at 8:55 AM Hilton Chain <hako <at> ultrarare.space> wrote:
> >
> > On Fri, 15 Nov 2024 22:30:40 +0800,
> > Hilton Chain wrote:
> > >
> > > Also for reproducibility, bin/zig is the only file differs and here's the diff,
> > > I don't know about this part so I currently have no idea on fixing it.
> >
> > This seem to be an upstream issue, Zig is reproducible only on the same machine.
> > I'll verify it and report to upstream.
>
> Zig defaults to `-march=native` when building for the host. Try
> ZIG_TARGET_MCPU=baseline when building stage3.
Yes, ZIG_TARGET_MCPU=baseline is passed to cmake.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 16 Nov 2024 17:06:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Nov 16, 2024 at 02:54:55PM +0800, Hilton Chain wrote:
> On Fri, 15 Nov 2024 22:30:40 +0800,
> Hilton Chain wrote:
> >
> > I have locally made the "use-system-paths" patch larger so that Zig can really
> > honor "CROSS_" environment variables.
> >
> > The next issue is cross building with pkg-config. Zig only invokes
> > "pkg-config", but we don't have a "pkg-config" with search path for target
> > inputs. I can add a pkg-config-for-zig to workaround this, and then... It's
> > dynamic linker path, I'll look into it soon.
I tried adding pkg-config-for-build as a work-around but it wasn't
enough without touching the zig compiler's source too, which I didn't
attempt yesterday.
> Adding a file with content like the following and passing --libc <this file> to
> zig works, RUNPATH is correct and no need to set CC then.
>
> --8<---------------cut here---------------start------------->8---
> include_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/include
> sys_include_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/include
> crt_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/lib
> msvc_lib_dir=
> kernel32_lib_dir=
> gcc_dir=
> --8<---------------cut here---------------end--------------->8---
Is this the layout of the file expected? That doesn't look too hard to
create in the build-system if necessary.
> For cross builds interpreter path like /lib/ld-linux-aarch64.so.1 is used in
> output binary, I'll find a way to fix it.
I was going to say to take a look at gcc-2.95, where we point all the
linkers for all the architectures to whatever the target architecture
is, but that won't work here since we have 1 zig binary and it can
compile for any architecture.
I'm going to suggest against adding a cross-libc for all the different
architectures as an input, that would be crazy.
(ins)efraim <at> 3900XT ~/workspace/zig$ git grep 'ld-linux-aarch64.so.1'
lib/libc/include/aarch64-linux-gnu/gnu/lib-names-lp64.h:#define LD_LINUX_AARCH64_SO "ld-linux-aarch64.so.1"
lib/libc/include/aarch64-linux-gnu/gnu/lib-names-lp64.h:#define LD_SO "ld-linux-aarch64.so.1"
lib/std/Build.zig:/// that contains the path `aarch64-linux-gnu/lib/ld-linux-aarch64.so.1`.
lib/std/Target.zig: .aarch64 => init("/lib/ld-linux-aarch64.so.1"),
Binary file stage1/zig1.wasm matches
Would it be possible to change the init("/path/to/ld.so") part to the
zig equivalent of (search-input-file inputs "/path/to/ld.so"), and then
when it is used from Guix the cross-libc will already be in the PATH and
therefore findable from zig's search through the vector¹ of the paths
inside PATH?
¹ I know it's not true but in my mind a vector and an array are the same
thing.
> > Also for reproducibility, bin/zig is the only file differs and here's the diff,
> > I don't know about this part so I currently have no idea on fixing it.
>
> This seem to be an upstream issue, Zig is reproducible only on the same machine.
> I'll verify it and report to upstream.
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 16 Nov 2024 19:01:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sun, 17 Nov 2024 01:03:59 +0800,
Efraim Flashner wrote:
>
> [1 <text/plain; utf-8 (quoted-printable)>]
> On Sat, Nov 16, 2024 at 02:54:55PM +0800, Hilton Chain wrote:
> > On Fri, 15 Nov 2024 22:30:40 +0800,
> > Hilton Chain wrote:
> > >
> > > I have locally made the "use-system-paths" patch larger so that Zig can really
> > > honor "CROSS_" environment variables.
> > >
> > > The next issue is cross building with pkg-config. Zig only invokes
> > > "pkg-config", but we don't have a "pkg-config" with search path for target
> > > inputs. I can add a pkg-config-for-zig to workaround this, and then... It's
> > > dynamic linker path, I'll look into it soon.
>
> I tried adding pkg-config-for-build as a work-around but it wasn't
> enough without touching the zig compiler's source too, which I didn't
> attempt yesterday.
>
> > Adding a file with content like the following and passing --libc <this file> to
> > zig works, RUNPATH is correct and no need to set CC then.
> >
> > --8<---------------cut here---------------start------------->8---
> > include_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/include
> > sys_include_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/include
> > crt_dir=/gnu/store/dfx90sc16nphh6bd07sjyri6x4s51zni-glibc-cross-aarch64-linux-gnu-2.39/lib
> > msvc_lib_dir=
> > kernel32_lib_dir=
> > gcc_dir=
> > --8<---------------cut here---------------end--------------->8---
>
> Is this the layout of the file expected? That doesn't look too hard to
> create in the build-system if necessary.
>
> > For cross builds interpreter path like /lib/ld-linux-aarch64.so.1 is used in
> > output binary, I'll find a way to fix it.
>
> I was going to say to take a look at gcc-2.95, where we point all the
> linkers for all the architectures to whatever the target architecture
> is, but that won't work here since we have 1 zig binary and it can
> compile for any architecture.
>
> I'm going to suggest against adding a cross-libc for all the different
> architectures as an input, that would be crazy.
>
> (ins)efraim <at> 3900XT ~/workspace/zig$ git grep 'ld-linux-aarch64.so.1'
> lib/libc/include/aarch64-linux-gnu/gnu/lib-names-lp64.h:#define LD_LINUX_AARCH64_SO "ld-linux-aarch64.so.1"
> lib/libc/include/aarch64-linux-gnu/gnu/lib-names-lp64.h:#define LD_SO "ld-linux-aarch64.so.1"
> lib/std/Build.zig:/// that contains the path `aarch64-linux-gnu/lib/ld-linux-aarch64.so.1`.
> lib/std/Target.zig: .aarch64 => init("/lib/ld-linux-aarch64.so.1"),
> Binary file stage1/zig1.wasm matches
>
> Would it be possible to change the init("/path/to/ld.so") part to the
> zig equivalent of (search-input-file inputs "/path/to/ld.so"), and then
> when it is used from Guix the cross-libc will already be in the PATH and
> therefore findable from zig's search through the vector¹ of the paths
> inside PATH?
>
> ¹ I know it's not true but in my mind a vector and an array are the same
> thing.
I have added a GUIX_ZIG_LIBC_DIR environment variable, to be set as output path
of cross-libc or libc by zig-build-system, patched Zig to search it and
concatenate it with "/lib/ld...".
Also added the file for --libc option in zig-build-system. Cross compilation is
available now. (only available in 0.12 for now, I'll port the patches to other
versions when I get up.)
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sun, 17 Nov 2024 01:40:03 GMT)
Full text and
rfc822 format available.
Message #87 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sat, 16 Nov 2024 14:54:55 +0800,
Hilton Chain wrote:
>
> > Also for reproducibility, bin/zig is the only file differs and here's the diff,
> > I don't know about this part so I currently have no idea on fixing it.
>
> This seem to be an upstream issue, Zig is reproducible only on the same machine.
> I'll verify it and report to upstream.
Opened a GitHub issue: <https://github.com/ziglang/zig/issues/22002>.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sun, 17 Nov 2024 07:18:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Nov 15, 2024 at 10:30:40PM +0800, Hilton Chain wrote:
> On Fri, 15 Nov 2024 11:29:10 +0800,
> Hilton Chain wrote:
> >
> > Good news: Thanks to this diff, I know how to add libc to RUNPATH now :)
> >
> > Another forced push, I have ensured consistent behavior for
> > (CROSS_)?LIBRARY_PATH and added libc RUNPATH without restoring the behavior
> > passing '-lc' to linker.
> >
> > Who said not going to implement a ld-wrapper within Zig? :P
> > Fortunately it was already there :)
> >
> > BTW, adding pkg-config to native-inputs works for ncdu.
>
> I have locally made the "use-system-paths" patch larger so that Zig can really
> honor "CROSS_" environment variables.
>
> The next issue is cross building with pkg-config. Zig only invokes
> "pkg-config", but we don't have a "pkg-config" with search path for target
> inputs. I can add a pkg-config-for-zig to workaround this, and then... It's
> dynamic linker path, I'll look into it soon.
I found a patch after the 0.13.0 release that switches from hardcoding
pkg-config to using the PKG_CONFIG environment variable and falling back
to pkg-config, so I backported it to 0.12 and was able to use that and
guix's regular pkg-config package. I've added those patches to the
wip-zig-bootstrap tree.
We now have a couple of phases that are before the 'build phase, do you
think it'd be better to consolidate them into a 'configure phase?
There's no 'configure' script to run, but it does do a lot of
preparation before the actual 'build phase...
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sun, 17 Nov 2024 14:53:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sun, 17 Nov 2024 15:16:13 +0800,
Efraim Flashner wrote:
>
> [1 <text/plain; utf-8 (quoted-printable)>]
> On Fri, Nov 15, 2024 at 10:30:40PM +0800, Hilton Chain wrote:
> > On Fri, 15 Nov 2024 11:29:10 +0800,
> > Hilton Chain wrote:
> > >
> > > Good news: Thanks to this diff, I know how to add libc to RUNPATH now :)
> > >
> > > Another forced push, I have ensured consistent behavior for
> > > (CROSS_)?LIBRARY_PATH and added libc RUNPATH without restoring the behavior
> > > passing '-lc' to linker.
> > >
> > > Who said not going to implement a ld-wrapper within Zig? :P
> > > Fortunately it was already there :)
> > >
> > > BTW, adding pkg-config to native-inputs works for ncdu.
> >
> > I have locally made the "use-system-paths" patch larger so that Zig can really
> > honor "CROSS_" environment variables.
> >
> > The next issue is cross building with pkg-config. Zig only invokes
> > "pkg-config", but we don't have a "pkg-config" with search path for target
> > inputs. I can add a pkg-config-for-zig to workaround this, and then... It's
> > dynamic linker path, I'll look into it soon.
>
> I found a patch after the 0.13.0 release that switches from hardcoding
> pkg-config to using the PKG_CONFIG environment variable and falling back
> to pkg-config, so I backported it to 0.12 and was able to use that and
> guix's regular pkg-config package. I've added those patches to the
> wip-zig-bootstrap tree.
Thanks, I have ported all patches and pushed. GUIX_ZIG_LIBC_DIR is changed to
GUIX_ZIG_GLIBC_LINKER and is set as full path in Guix side because I don't want
mess with strings in Zig side...
> We now have a couple of phases that are before the 'build phase, do you
> think it'd be better to consolidate them into a 'configure phase?
> There's no 'configure' script to run, but it does do a lot of
> preparation before the actual 'build phase...
I have merged these phases into configure, forgot to change commit log though.
The reproducibility issue is related to kernel version from target ("native" by
default) information, to address this we need to specify a target for native
builds too.[1]
---
[1]: https://github.com/ziglang/zig/issues/22002#issuecomment-2480933071
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Mon, 18 Nov 2024 12:01:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sun, 17 Nov 2024 22:51:48 +0800,
Hilton Chain wrote:
>
> The reproducibility issue is related to kernel version from target ("native" by
> default) information, to address this we need to specify a target for native
> builds too.
Specifying a target makes Zig behave like in cross-compilation, fortunately
workaround for zig-build-system still applies here too.
Marked the commit as DRAFT since I'm still building it.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Tue, 19 Nov 2024 13:15:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Sun, 17 Nov 2024 22:51:48 +0800,
Hilton Chain wrote:
>
> Thanks, I have ported all patches and pushed. GUIX_ZIG_LIBC_DIR is changed to
> GUIX_ZIG_GLIBC_LINKER and is set as full path in Guix side because I don't want
> mess with strings in Zig side...
Reworked this, patched Zig to search dynamic linker in CROSS_LIBRARY_PATH or
LIBRARY_PATH (added in the use-system-paths patch), no extra environment
variable introduced now.
> > We now have a couple of phases that are before the 'build phase, do you
> > think it'd be better to consolidate them into a 'configure phase?
> > There's no 'configure' script to run, but it does do a lot of
> > preparation before the actual 'build phase...
>
> I have merged these phases into configure, forgot to change commit log though.
Moved zig-target and zig-build-system's configure phase to (guix build
zig-utils) to avoid dependency issue, as building Zig now uses them too.
Removed nonfree files (IETF RFC documents) from Zig source.
I'll take a look at Zig package manager support.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 21 Nov 2024 13:08:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Tue, 19 Nov 2024 21:13:50 +0800,
Hilton Chain wrote:
>
> I'll take a look at Zig package manager support.
Added support for Zig package manager (build.zig.zon) and switched default Zig
to zig-0.13, please see the two DRAFT commits. I have also updated and added
some packages as examples.
Since Zig has command line option changes in 0.11 (those are affecting us:
"-Drelease-safe" -> "-Doptimeze=ReleaseSafe", new "-j"), I added a zig-arguments
procedure which returns an alist mapping command line options.
Motiejus raised concern about Zig's bundled abilist file[1][2], which is
generated from sources of various glibc versions. How should we treat it?
[1]: https://github.com/ziglang/zig/tree/master/lib/libc/glibc
[2]: https://github.com/ziglang/glibc-abi-tool
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 28 Nov 2024 11:09:01 GMT)
Full text and
rfc822 format available.
Message #105 received at 74217 <at> debbugs.gnu.org (full text, mbox):
I started to learn Zig these days and adjusted patches for Zig a bit.
Other than this, I have added a install-source? argument to zig-build-system, it
can now install package source to "/src/<name>-<version>".
"-Dtarget" is used in zig-build-system's native builds as well, same as Zig for
reproducibility.
Made "#:zig-inputs" a private keyword, its value will be passed to inputs like
cargo-build-system (the build system doesn't extract the whole closure for now,
this can be added in the future depending on how Zig ecosystem develops).
Set ZIG_GLOBAL_CACHE_DIR and ZIG_LOCAL_CACHE_DIR to "/tmp/zig-cache", and set
ZIG_LIBC instead of using "zig build --libc", for convenience.
I think this is mostly ready ( again :) ). If there's nothing else missing,
I'll post the current status and call for packages to test the build system on
guix-devel, together with the concern on generated files.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 28 Nov 2024 12:43:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, Nov 28, 2024 at 1:08 PM Hilton Chain <hako <at> ultrarare.space> wrote:
>
> <...> together with the concern on generated files.
Hi Hilton,
The only remaining, to my knowledge, binary file is `abilists`, which,
once you have `zig` binary, can be generated this way:
git clone https://github.com/ziglang/glibc-abi-tool; cd glibc-abi-tool
git checkout fc5d0a7046b76795e4219f8f168e118ec29fbc53
/path/to/zig-0.13/bin/zig run consolidate.zig
mv abilists /path/to/zig/lib/libc/glibc/abilist
For 0.12.1:
rm -fr glibc/2.39
sed -i '133d' consolidate.zig
/path/to/zig-0.12.1/bin/zig run consolidate.zig
mv abilists /path/to/zig/lib/libc/glibc/abilist
I wasn't able to generate it for 0.11, but perhaps it's not as
important, as I imagine there are very few people, if any, still
developing on 0.11. Since one needs abilists *only* to cross-compile
to non-guix glibc targets, it sounds like a vanishingly small use case
for Guix to support.
Motiejus
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 28 Nov 2024 15:21:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 28 Nov 2024 20:41:10 +0800,
Motiejus Jakštys wrote:
>
> On Thu, Nov 28, 2024 at 1:08 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> >
> > <...> together with the concern on generated files.
>
> Hi Hilton,
>
> The only remaining, to my knowledge, binary file is `abilists`, which,
> once you have `zig` binary, can be generated this way:
>
> git clone https://github.com/ziglang/glibc-abi-tool; cd glibc-abi-tool
> git checkout fc5d0a7046b76795e4219f8f168e118ec29fbc53
> /path/to/zig-0.13/bin/zig run consolidate.zig
> mv abilists /path/to/zig/lib/libc/glibc/abilist
>
> For 0.12.1:
> rm -fr glibc/2.39
> sed -i '133d' consolidate.zig
> /path/to/zig-0.12.1/bin/zig run consolidate.zig
> mv abilists /path/to/zig/lib/libc/glibc/abilist
>
> I wasn't able to generate it for 0.11, but perhaps it's not as
> important, as I imagine there are very few people, if any, still
> developing on 0.11. Since one needs abilists *only* to cross-compile
> to non-guix glibc targets, it sounds like a vanishingly small use case
> for Guix to support.
>
> Motiejus
Thanks! Then I'll keep abilists removed before we can reproduce one :)
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 28 Nov 2024 20:15:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, Nov 28, 2024 at 5:20 PM Hilton Chain <hako <at> ultrarare.space> wrote:
>
> On Thu, 28 Nov 2024 20:41:10 +0800,
> Motiejus Jakštys wrote:
> >
> > On Thu, Nov 28, 2024 at 1:08 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> > >
> > > <...> together with the concern on generated files.
> >
> > Hi Hilton,
> >
> > The only remaining, to my knowledge, binary file is `abilists`, which,
> > once you have `zig` binary, can be generated this way:
> >
> > git clone https://github.com/ziglang/glibc-abi-tool; cd glibc-abi-tool
> > git checkout fc5d0a7046b76795e4219f8f168e118ec29fbc53
> > /path/to/zig-0.13/bin/zig run consolidate.zig
> > mv abilists /path/to/zig/lib/libc/glibc/abilist
> >
> > For 0.12.1:
> > rm -fr glibc/2.39
> > sed -i '133d' consolidate.zig
> > /path/to/zig-0.12.1/bin/zig run consolidate.zig
> > mv abilists /path/to/zig/lib/libc/glibc/abilist
> >
> > I wasn't able to generate it for 0.11, but perhaps it's not as
> > important, as I imagine there are very few people, if any, still
> > developing on 0.11. Since one needs abilists *only* to cross-compile
> > to non-guix glibc targets, it sounds like a vanishingly small use case
> > for Guix to support.
> >
> > Motiejus
>
> Thanks! Then I'll keep abilists removed before we can reproduce one :)
Seems reproducible, at least on my machine. Let's start at the last
commit before 0.13.0 that updates abilists[1]:
commit 53137050f8718c923983878904f5467446d28ba5
Author: Andrew Kelley <andrew <at> ziglang.org>
Date: 2024-06-06T03:43:41+03:00
glibc: update abilists file
generated from ziglang/glibc-abi-tool commit
fc5d0a7046b76795e4219f8f168e118ec29fbc53 which now contains glibc 2.39
lib/libc/glibc/abilists | Bin 214842 -> 217016 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
sha256sum 0.13.0:lib/libc/glibc/abilists is the same as if I generate
abilists myself on fc5d0a7046b76795e4219f8f168e118ec29fbc53 using zig
0.13.0. I get a62c6860a5db1f575b385fd45357f2c841abc84387b8047ca0ebf98a44d1947e.
Great to see you progressing so quickly. Have fun with the remaining bits!
Motiejus
[1]: https://github.com/ziglang/zig/commit/53137050f8718c923983878904f5467446d28ba5
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 28 Nov 2024 20:16:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, Nov 28, 2024 at 10:12 PM Motiejus Jakštys <motiejus <at> jakstys.lt> wrote:
>
> On Thu, Nov 28, 2024 at 5:20 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> > Thanks! Then I'll keep abilists removed before we can reproduce one :)
Ahh, now I realized you probably meant removed in 0.11. Sorry for the noise!
Motiejus
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 28 Nov 2024 20:56:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Nov 28, 2024 at 5:20 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> Thanks! Then I'll keep abilists removed before we can reproduce one :)
OK here it is for 0.11:
1. check out glibc-abi-tool 13576b1ea957882be7ff2c99f4cdc27454930219
2. rm -fr glibc/2.3{5,6,7,8}
3. apply the attached patch.
4. /path/to/zig-0.11/bin/zig run consolidate.zig
... which results in abilists
546e3c64b5c972b45c4c5c3e81fa1c73282db9377d57ae870d7abcb276f9605c.
Motiejus
[Backport-consolidate.zig-to-zig-0.11.0.patch (text/x-patch, attachment)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 29 Nov 2024 12:27:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Fri, 29 Nov 2024 04:53:57 +0800,
Motiejus Jakštys wrote:
>
> [1 <text/plain; UTF-8 (quoted-printable)>]
> On Thu, Nov 28, 2024 at 5:20 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> > Thanks! Then I'll keep abilists removed before we can reproduce one :)
>
> OK here it is for 0.11:
>
> 1. check out glibc-abi-tool 13576b1ea957882be7ff2c99f4cdc27454930219
> 2. rm -fr glibc/2.3{5,6,7,8}
> 3. apply the attached patch.
> 4. /path/to/zig-0.11/bin/zig run consolidate.zig
>
> ... which results in abilists
> 546e3c64b5c972b45c4c5c3e81fa1c73282db9377d57ae870d7abcb276f9605c.
>
> Motiejus
> [2 Backport-consolidate.zig-to-zig-0.11.0.patch <text/x-patch; US-ASCII (base64)>]
> From 23135302904467aa2e814500af6327408c46f52e Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Motiejus=20Jak=C5=A1tys?= <motiejus <at> jakstys.lt>
> Date: Thu, 28 Nov 2024 22:52:13 +0200
> Subject: [PATCH] Backport consolidate.zig to zig 0.11.0
>
> ---
> consolidate.zig | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
Thanks very much! I have added abilists for 0.9 and 0.10 as well.
Also supported "-Wl,-rpath=" from pkg-config output in the fix-runpath patch.
Should be enough for current packages.
Just realised the weekend is coming, I'll send to guix-devel soon. ;)
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Fri, 29 Nov 2024 14:52:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Fri, 29 Nov 2024 20:25:43 +0800,
Hilton Chain wrote:
>
> Just realised the weekend is coming, I'll send to guix-devel soon. ;)
https://lists.gnu.org/archive/html/guix-devel/2024-11/msg00271.html
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sun, 01 Dec 2024 19:34:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Fri, Nov 29, 2024 at 2:25 PM Hilton Chain <hako <at> ultrarare.space> wrote:
>
> On Fri, 29 Nov 2024 04:53:57 +0800,
> Motiejus Jakštys wrote:
> >
> > [1 <text/plain; UTF-8 (quoted-printable)>]
> > On Thu, Nov 28, 2024 at 5:20 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> > > Thanks! Then I'll keep abilists removed before we can reproduce one :)
> >
> > OK here it is for 0.11:
> >
> > 1. check out glibc-abi-tool 13576b1ea957882be7ff2c99f4cdc27454930219
> > 2. rm -fr glibc/2.3{5,6,7,8}
> > 3. apply the attached patch.
> > 4. /path/to/zig-0.11/bin/zig run consolidate.zig
> >
> > ... which results in abilists
> > 546e3c64b5c972b45c4c5c3e81fa1c73282db9377d57ae870d7abcb276f9605c.
> >
> > Motiejus
> > [2 Backport-consolidate.zig-to-zig-0.11.0.patch <text/x-patch; US-ASCII (base64)>]
> > From 23135302904467aa2e814500af6327408c46f52e Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Motiejus=20Jak=C5=A1tys?= <motiejus <at> jakstys.lt>
> > Date: Thu, 28 Nov 2024 22:52:13 +0200
> > Subject: [PATCH] Backport consolidate.zig to zig 0.11.0
> >
> > ---
> > consolidate.zig | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
>
> Thanks very much! I have added abilists for 0.9 and 0.10 as well.
For the record, I have smoke-tested abilists on 0.9, 0.10, 0.11.0,
0.12.1 and 0.13. The test was as follows:
1. create a "hello world" C program that uses printf.
2. /gnu/.../zig-VERSION/bin/zig cc -target x86_64-linux-gnu.2.28
hello.c -o hello
3. readelf -Ws hello
4. observe line (3) has line "printf <at> GLIBC_2.2.5".
5. run `hello` on non-guix and observe expected output.
Regards,
Motiejus
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Mon, 02 Dec 2024 05:13:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 28 Nov 2024 19:08:09 +0800,
Hilton Chain wrote:
>
> Made "#:zig-inputs" a private keyword, its value will be passed to inputs like
> cargo-build-system (the build system doesn't extract the whole closure for
> now, this can be added in the future depending on how Zig ecosystem develops).
Just thought if we can avoid using #:zig-inputs, it turns out doing so is quite
easy:
--8<---------------cut here---------------start------------->8---
@@ -330,9 +327,20 @@ (define-public zig-zls-0.12
(file-name (git-file-name name version))
(sha256
(base32
- "1ini1ifa9b0v2ika3sqsiiv2p7v9npfslss45280yxwn2pjqmn7n"))))
+ "1ini1ifa9b0v2ika3sqsiiv2p7v9npfslss45280yxwn2pjqmn7n"))
+ (modules '((guix build utils)))
+ (snippet
+ #~(begin
+ (substitute* "build.zig"
+ (("(b\\.dependency.\")diffz" _ prefix)
+ (string-append prefix "zig-diffz"))
+ (("(b\\.dependency.\")known_folders" _ prefix)
+ (string-append prefix "zig-known-folders")))
+ (substitute* "build.zig.zon"
+ (("\\.diffz") ".@\"zig-diffz\"")
+ (("\\.known_folders") ".@\"zig-known-folders\""))))))
(build-system zig-build-system)
- (inputs (list zig-0.12))
+ (inputs (list zig-0.12 zig-diffz zig-known-folders))
(arguments
(let ((version-data-path
#~(string-append "-Dversion_data_path="
@@ -344,7 +352,4 @@ (define-public zig-zls-0.12
#:zig-build-flags
#~(list #$version-data-path)
#:zig-test-flags
- #~(list #$version-data-path)
- #:zig-inputs
- `(("known_folders" ,zig-known-folders)
- ("diffz" ,zig-diffz)))))))
+ #~(list #$version-data-path))))))
(define-public zig-zls-0.13
(package
--8<---------------cut here---------------end--------------->8---
I also continued the bootstrap path to current master:
https://paste.sr.ht/~hako/584dd15fd1614f23e6a421b906092a1b28614148
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Mon, 02 Dec 2024 07:42:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 74217 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Dec 01, 2024 at 09:32:01PM +0200, Motiejus Jakštys wrote:
> On Fri, Nov 29, 2024 at 2:25 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> >
> > On Fri, 29 Nov 2024 04:53:57 +0800,
> > Motiejus Jakštys wrote:
> > >
> > > [1 <text/plain; UTF-8 (quoted-printable)>]
> > > On Thu, Nov 28, 2024 at 5:20 PM Hilton Chain <hako <at> ultrarare.space> wrote:
> > > > Thanks! Then I'll keep abilists removed before we can reproduce one :)
> > >
> > > OK here it is for 0.11:
> > >
> > > 1. check out glibc-abi-tool 13576b1ea957882be7ff2c99f4cdc27454930219
> > > 2. rm -fr glibc/2.3{5,6,7,8}
> > > 3. apply the attached patch.
> > > 4. /path/to/zig-0.11/bin/zig run consolidate.zig
> > >
> > > ... which results in abilists
> > > 546e3c64b5c972b45c4c5c3e81fa1c73282db9377d57ae870d7abcb276f9605c.
> > >
> > > Motiejus
> > > [2 Backport-consolidate.zig-to-zig-0.11.0.patch <text/x-patch; US-ASCII (base64)>]
> > > From 23135302904467aa2e814500af6327408c46f52e Mon Sep 17 00:00:00 2001
> > > From: =?UTF-8?q?Motiejus=20Jak=C5=A1tys?= <motiejus <at> jakstys.lt>
> > > Date: Thu, 28 Nov 2024 22:52:13 +0200
> > > Subject: [PATCH] Backport consolidate.zig to zig 0.11.0
> > >
> > > ---
> > > consolidate.zig | 8 ++------
> > > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > Thanks very much! I have added abilists for 0.9 and 0.10 as well.
>
> For the record, I have smoke-tested abilists on 0.9, 0.10, 0.11.0,
> 0.12.1 and 0.13. The test was as follows:
>
> 1. create a "hello world" C program that uses printf.
> 2. /gnu/.../zig-VERSION/bin/zig cc -target x86_64-linux-gnu.2.28
> hello.c -o hello
> 3. readelf -Ws hello
> 4. observe line (3) has line "printf <at> GLIBC_2.2.5".
> 5. run `hello` on non-guix and observe expected output.
Thank you for sharing that syntax for targeting specific glibc versions.
I'm continuing to try to build zig-0.10.0-610 on riscv64. I've had more
luck with powerpc64le but it's not the most convenient thing with
passing build targets between my computer and berlin.
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Thu, 05 Dec 2024 06:34:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Mon, 02 Dec 2024 13:11:53 +0800,
Hilton Chain wrote:
>
> On Thu, 28 Nov 2024 19:08:09 +0800,
> Hilton Chain wrote:
> >
> > Made "#:zig-inputs" a private keyword, its value will be passed to inputs like
> > cargo-build-system (the build system doesn't extract the whole closure for
> > now, this can be added in the future depending on how Zig ecosystem develops).
>
> Just thought if we can avoid using #:zig-inputs, it turns out doing so is quite
> easy:
Added two procedures producing origin snippets in (gnu packages zig-xyz).
'add-build.zig.zon' for generating build.zig.zon, currently unused.
'rename-zig-dependencies' for replacing #:zig-inputs.
I'll try to make unpack-dependencies phase reading dependencies from
build.zig.zon instead of input labels so that we can have more specificity.
Information forwarded
to
bug-guix <at> gnu.org, Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug#74217; Package
guix.
(Sat, 07 Dec 2024 14:09:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 74217 <at> debbugs.gnu.org (full text, mbox):
On Thu, 05 Dec 2024 14:27:14 +0800,
Hilton Chain wrote:
>
> On Mon, 02 Dec 2024 13:11:53 +0800,
> Hilton Chain wrote:
> >
> > On Thu, 28 Nov 2024 19:08:09 +0800,
> > Hilton Chain wrote:
> > >
> > > Made "#:zig-inputs" a private keyword, its value will be passed to inputs like
> > > cargo-build-system (the build system doesn't extract the whole closure for
> > > now, this can be added in the future depending on how Zig ecosystem develops).
> >
> > Just thought if we can avoid using #:zig-inputs, it turns out doing so is quite
> > easy:
>
> Added two procedures producing origin snippets in (gnu packages zig-xyz).
>
> 'add-build.zig.zon' for generating build.zig.zon, currently unused.
> 'rename-zig-dependencies' for replacing #:zig-inputs.
Moved to (gnu packages zig).
> I'll try to make unpack-dependencies phase reading dependencies from
> build.zig.zon instead of input labels so that we can have more specificity.
Changed install path for Zig packages to /src/zig, added a GUIX_ZIG_PACKAGE_PATH
search path (currently only in Zig 0.13 to avoid rebuilds).
Phase unpack-dependencies is changed to:
1. Find dependencies in build.zig.zon.
2. Find inputs in GUIX_ZIG_PACKAGE_PATH.
3. Per dependency, invoke "zig fetch" on matched input ('^dependency[-.]?', this
pattern expands available specificity to minor version, in case it's unavoidable
to propagate multiple versions of the same package into build environment).
With above changes, it's possible to reuse dependencies packaged in Guix, for example:
--8<---------------cut here---------------start------------->8---
cd $(mktemp -d)
cp --recursive --no-preserve=all $(<...>/pre-inst-env guix build --source zig-httpz)/. .
<...>/pre-inst-env guix shell --development zig-httpz
<...>/pre-inst-env guile -c "((@@ (guix build zig-build-system) unpack-dependencies))"
zig build
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
cd $(mktemp -d)
git clone https://github.com/karlseguin/http.zig && cd http.zig
git checkout zig-0.13
<...>/pre-inst-env guile -c "(eval ((@ (gnu packages zig) rename-zig-dependencies) '((\"metrics\" . \"zig-metrics\") (\"websocket\" . \"zig-websocket\"))) (interaction-environment))"
<...>/pre-inst-env guix shell zig zig-metrics zig-websocket
<...>/pre-inst-env guile -c "((@@ (guix build zig-build-system) unpack-dependencies))"
zig build
--8<---------------cut here---------------end--------------->8---
Reply sent
to
Hilton Chain <hako <at> ultrarare.space>:
You have taken responsibility.
(Tue, 31 Dec 2024 15:41:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ekaitz Zarraga <ekaitz <at> elenq.tech>:
bug acknowledged by developer.
(Tue, 31 Dec 2024 15:41:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 74217-done <at> debbugs.gnu.org (full text, mbox):
On Thu, 28 Nov 2024 19:08:09 +0800,
Hilton Chain wrote:
>
> I think this is mostly ready ( again :) ). If there's nothing else missing,
> I'll post the current status and call for packages to test the build system on
> guix-devel.
Applied Zig bootstrap as 40b9f33066...42e32d52c3.
I'll delete wip-zig-bootstrap, move Zig libraries left there (currently unused
by other packages) to zig-team branch and continue the bootstrap chain on
zig-next branch.
Manifest for all Zig packages is available at "etc/teams/zig/zig-manifest.scm".
BTW I just realised that on reusing procedures from Guix, `guix repl' is more
convenient than `guile -c' in terms of load paths:
--8<---------------cut here---------------start------------->8---
echo "((assoc-ref (@ (guix build zig-build-system) %standard-phases) 'unpack-dependencies))" | guix repl -t machine
--8<---------------cut here---------------end--------------->8---
Builds on ci.guix.gnu.org is a bit slower than my estimation, but hopefully
we'll have x86_64-linux substitutes on 2025-01-01. :)
Closing.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 29 Jan 2025 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 192 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.