Do not install new binutils on the system, only use it in gcc

[GuillaumeGomez]

View all comments

As discussed in #161218.

cc @RalfJung @antoyo
r? @Kobzol

[GuillaumeGomez]

@bors try jobs=dist*linux

[antoyo]

It seems you forgot to add --with-as and --with-ld.

[GuillaumeGomez]

It seems you forgot to add --with-as and --with-ld.

Indeed...

[GuillaumeGomez]

@bors try jobs=dist*linux

[Kobzol]

Note that here you are providing as and ld to a GCC that will later build the libgccjit.so that we ship. I didn't realize it in the previous PR, but it's weird that this actually does something. I would expect that we have to provide the binutils to the build of our libgccjit.so, which is likely what the make install does (?).

View changes since the review

[GuillaumeGomez]

I would as well, but I'm unclear whether it's only used to be gcc or it's the paths gcc will use when running.

[GuillaumeGomez]

s/only used to be gcc/only used to build gcc/

Very annoying that we can't edit currently. ^^'

[antoyo]

Isn't this the configure for the GCC 9.5?
The --with-as flags probably need to be in the dist.sh file to be in our libgccjit, no?

[fbstj]

Suggested change

	mkdir /binutils-install
	mkdir $BINUTILS_ROOT_PATH

am I missing something?

View changes since the review

[GuillaumeGomez]

Nope you're right.

[rust-bors]

💔 Test for 28ad8c1 failed: CI. Failed jobs:

• try - dist-i686-linux (web logs, enhanced plaintext logs)
• try - dist-x86_64-linux (web logs, enhanced plaintext logs)

[RalfJung]

Yes this seems to fix the Miri build :)

[antoyo]

Yes this seems to fix the Miri build :)

libgccjit is not built correctly here, but I guess this is good news.

[GuillaumeGomez]

Yes this seems to fix the Miri build :)

libgccjit is not built correctly here, but I guess this is good news.

What's wrong?

[GuillaumeGomez]

Now that github seems to be mostly back, let's restart the jobs.

@bors try jobs=dist*linux

[GuillaumeGomez]

Seems like binutils and the compiler are kinda tied together? So if we use one version of binutils, we need to use it all the way. So what do we do? Should we try with binutils 2.46?

[GuillaumeGomez]

Let's try like this.

@bors try jobs=dist*linux

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[JonathanBrouwer]

@bors p=4 scheduling

[rust-bors]

💔 Test for bb9f25d failed: CI. Failed job:

• auto - x86_64-msvc-1 (web logs, enhanced plaintext logs)

[GuillaumeGomez]

@bors retry

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[GuillaumeGomez]

It was the same error twice in a row:

curl: (35) Recv failure: Connection was reset

@Kobzol Is something wrong?

[JonathanBrouwer]

@GuillaumeGomez That's still the rust-log-analyzer from the previous failure :D

[GuillaumeGomez]

Oh. Stress--

[rust-bors]

☀️ Test successful - CI
Approved by: Kobzol
Duration: 2h 57m 30s
Pushing b662191 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 526c36b (parent) -> b662191 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard b66219142c937562f2ff8e083be2a2b25b20199e --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-gnu-llvm-22-2: 1h 39m -> 1h 1m (-38.5%)
2. x86_64-gnu-llvm-22-3: 1h 54m -> 1h 14m (-35.0%)
3. x86_64-gnu-gcc-core-tests: 16m 48s -> 10m 57s (-34.8%)
4. x86_64-gnu-stdlib-semver-check: 15m 11s -> 10m 18s (-32.2%)
5. arm-android: 1h 17m -> 1h 42m (+32.0%)
6. i686-gnu-nopt-1: 2h 13m -> 1h 32m (-31.1%)
7. x86_64-gnu-gcc: 58m 42s -> 1h 16m (+29.5%)
8. x86_64-gnu-next-trait-solver-polonius: 59m 30s -> 41m 59s (-29.4%)
9. dist-i586-gnu-i586-i686-musl: 27m 36s -> 19m 35s (-29.0%)
10. dist-x86_64-linux-alt: 1h 50m -> 2h 21m (+27.8%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (b662191): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (secondary -7.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.0%	[-7.0%, -7.0%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 2.9%, secondary 1.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	2.9%	[2.2%, 3.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	2.9%	[2.9%, 2.9%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 470.08s -> 470.067s (-0.00%)
Artifact size: 400.00 MiB -> 400.02 MiB (0.00%)

[RalfJung]

Miri is broken again :(

[RalfJung]

Miri worked fine with 1f6030a so whatever changed since then apparently re-introduced the problem.

(Also why does this PR have 13 commits? Did we really have to land all that back-and-forth in main?)

[RalfJung]

Here's the diff since the last version that I tried that worked. That's, like, a complete rewrite. I didn't test Miri again since I had no way of knowing that the PR was completely rewritten.