Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Python and Clang on x86 dist images #81489

Merged
merged 2 commits into from
Jan 30, 2021

Conversation

nikic
Copy link
Contributor

@nikic nikic commented Jan 28, 2021

LLVM 12 no longer builds with Python 2, so install Python 3 in
preparation for the upgrade (#81451).

However, Clang 10 does not build with Python 3, so we need update
to Clang 11 as well, which supports both.

Unfortunately, doing so results in errors while linking the
libLLVM.so into other binaries:

__morestack: invalid needed version 2

This is fixed by using LLD instead. Possibly this is due to a binutils
linker bug, but updating to the latest binutils version does not fix
it.

r? @Mark-Simulacrum
cc @cuviper

LLVM 12 no longer builds with Python 2, so install Python 3 in
preparatin.

However, Clang 10 does not build with Python 3, so we need update
to Clang 11 as well, which supports both.

Unfortunately, doing so results in errors while linking the
libLLVM.so into other binaries:
> __morestack: invalid needed version 2

This is fixed by using LLD instead. Possibly this is due to a binutils
linker bug, but updating to the latest binutils version does not fix
it.
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 28, 2021
@Mark-Simulacrum
Copy link
Member

I think the changes here shouldn't impact end users at all. We should make sure that LLVM will still build fine without lld/super-recent clang with more modern toolchains (e.g., on Ubuntu 20.04 LTS with roughly just build-essential), but I presume that's checked upstream to some extent too.

r=me if I'm correct about the above.

@cuviper
Copy link
Member

cuviper commented Jan 28, 2021

FWIW, there was also a case of the __morestack issue with clang and LLVM 11 here:
https://zulip-archive.rust-lang.org/131828tcompiler/25509morestackerrorwhenbuildinglibrustcdriver.html

@nikic
Copy link
Contributor Author

nikic commented Jan 28, 2021

Yeah, so the linker problem here isn't related to LLVM 12, it also occurs with LLVM 11 and is somehow related to use of Clang 11 and the BFD linker (and possibly some environment factors -- who knows with this old distro) to compile libLLVM.so and then link it.

LLVM 12 itself does build fine (and link into rustc) on Ubuntu 20.04 with a standard toolchain, as that's the system I'm on.

@Mark-Simulacrum
Copy link
Member

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Jan 28, 2021

📌 Commit e066dea has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 28, 2021
This avoids a conflict if llvm.thin-lto=true is combined with an
explicit llvm.use-linker=lld.
@nikic
Copy link
Contributor Author

nikic commented Jan 28, 2021

I've switched the LLVM_ENABLE_LLD use when llvm.thin-lto=true is set to use LLVM_USE_LINKER=lld instead, as otherwise one can't use llvm.thin-lto=true and llvm.use-linker=lld at the same time.

Missed this previously as I did not delete obj/ between rebuilds.

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jan 28, 2021

📌 Commit a84ff2b has been approved by Mark-Simulacrum

@bors
Copy link
Contributor

bors commented Jan 29, 2021

⌛ Testing commit a84ff2b with merge 800ff69df656ec8d4a240efe8fe8c7589424393c...

@bors
Copy link
Contributor

bors commented Jan 29, 2021

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 29, 2021
@rust-log-analyzer
Copy link
Collaborator

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

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

@Aaron1011
Copy link
Member

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 29, 2021
@bors
Copy link
Contributor

bors commented Jan 30, 2021

⌛ Testing commit a84ff2b with merge cb6787a...

@bors
Copy link
Contributor

bors commented Jan 30, 2021

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing cb6787a to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 30, 2021
@bors bors merged commit cb6787a into rust-lang:master Jan 30, 2021
@rustbot rustbot added this to the 1.51.0 milestone Jan 30, 2021
@RalfJung
Copy link
Member

Looks like this PR broke the produced toolchains: #81489

nikic added a commit to nikic/rust that referenced this pull request Jan 30, 2021
…ark-Simulacrum"

This reverts commit cb6787a, reversing
changes made to 0248c6f.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants