GNU bug report logs - #74217
Bootstrapping Zig with no Binary Blobs

Previous Next

Package: guix;

Reported by: Ekaitz Zarraga <ekaitz <at> elenq.tech>

Date: Tue, 5 Nov 2024 21:49:02 UTC

Owned by: Ekaitz Zarraga <ekaitz <at> elenq.tech>

Severity: normal

Done: Hilton Chain <hako <at> ultrarare.space>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Hilton Chain <hako <at> ultrarare.space>
To: 74217 <at> debbugs.gnu.org
Cc: Motiejus Jakštys <motiejus <at> jakstys.lt>, Noé Lopez <noe <at> xn--no-cja.eu>, dan <i <at> dan.games>, Efraim Flashner <efraim <at> flashner.co.il>, Ekaitz Zarraga <ekaitz <at> elenq.tech>
Subject: bug#74217: Bootstrapping Zig with no Binary Blobs
Date: Fri, 15 Nov 2024 11:29:10 +0800
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




This bug report was last modified 193 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.