bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74217: Bootstrapping Zig with no Binary Blobs


From: Efraim Flashner
Subject: bug#74217: Bootstrapping Zig with no Binary Blobs
Date: Sat, 16 Nov 2024 19:03:59 +0200

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@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@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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]