sanxiyn ( Seo Sanghyeon )

The first thing to do is to check the status of LLVM. Is the support merged? If so, when did it merge? (It is to check whether Rust's LLVM is recent enough.) How does one use the support? Etc.

sanxiyn

comment created time in a month

startedgatling/gatling

started time in 2 months

startedspotify/scio

started time in 2 months

startedlocationtech/geotrellis

started time in 2 months

startedghostdogpr/caliban

started time in 2 months

startedrune-rs/rune

started time in 2 months

startedgitbucket/gitbucket

started time in 2 months

startedlinkerd/linkerd

started time in 2 months

startedekzhang/crepe

started time in 2 months

startedgluesql/gluesql

started time in 2 months

starteddimforge/rapier

started time in 2 months

issue commentfishinabarrel/linux-kernel-module-rust

Architecture support (tracking issue)

C-SKY LLVM port got proposed in August 2020.

geofft

comment created time in 2 months

startedgoogle/autocxx

started time in 2 months

starteddtolnay/cxx

started time in 2 months

startedwasmerio/wasmer

started time in 2 months

startedsoftwaremill/sttp

started time in 3 months

startedbevyengine/bevy

started time in 3 months

startedsuhr/sana

started time in 3 months

startedscalapb/ScalaPB

started time in 3 months

issue commentrust-lang/rust

Bit-for-bit deterministic / reproducible builds

Yes, I think we should open a new issue for reproducible build CI. I also think it would be impractical for a while due to computational demand, but then I am not a member of infra team.

infinity0

comment created time in 3 months

issue closedrust-lang/rust

Bit-for-bit deterministic / reproducible builds

It would be good if rustc could generate bit-for-bit reproducible results, even in the presence of minor system environment differences. Currently we have quite a large diff: e.g. see txt diff for 1.9.0 or perhaps txt diff for 1.10.0 a few days after I'm posting this. (You might want to "save link as" instead of displaying it directly in the browser.)

Much of the diff output is due to build-id differences, which can be ignored since they are caused by other deeper issues and will go away once these deeper issues are fixed. One example of a deeper issue is this:

│   │   │   ├── ./usr/lib/i386-linux-gnu/librustc_data_structures-e8edd0fd.so
│   │   │   │   ├── readelf --wide --file-header {}
│   │   │   │   │ @@ -6,15 +6,15 @@
│   │   │   │   │    OS/ABI:                            UNIX - System V
│   │   │   │   │    ABI Version:                       0
│   │   │   │   │    Type:                              DYN (Shared object file)
│   │   │   │   │    Machine:                           Intel 80386
│   │   │   │   │    Version:                           0x1
│   │   │   │   │    Entry point address:               0x4620
│   │   │   │   │    Start of program headers:          52 (bytes into file)
│   │   │   │   │ -  Start of section headers:          338784 (bytes into file)
│   │   │   │   │ +  Start of section headers:          338780 (bytes into file)
│   │   │   │   │    Flags:                             0x0
│   │   │   │   │    Size of this header:               52 (bytes)
│   │   │   │   │    Size of program headers:           32 (bytes)
│   │   │   │   │    Number of program headers:         8
│   │   │   │   │    Size of section headers:           40 (bytes)
│   │   │   │   │    Number of section headers:         30
│   │   │   │   │    Section header string table index: 29
│   │   │   │   ├── readelf --wide --program-header {}

Here are the system variations that might be causing these issues. I myself am not that familiar with ELF, but perhaps someone else here would know why the section header is 4 bytes later in the first vs second builds.

closed time in 3 months

infinity0

issue commentrust-lang/rust

Bit-for-bit deterministic / reproducible builds

We should use individual issues tagged A-reproducibility going forward. Closing.

infinity0

comment created time in 3 months