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

Linux dist: don't include unique symbols in libLLVM #78946

Merged
merged 1 commit into from
Nov 11, 2020

Conversation

jethrogb
Copy link
Contributor

Fixes #76980

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 11, 2020
@jethrogb
Copy link
Contributor Author

jethrogb commented Nov 11, 2020

Can I get a try build?

Do we need to do something similar on other Linux targets? We don't build libstdc++ for every target today, just using the system-supplied one. Building a custom version seems like a lot of effort and maintenance headache going forward, if we need a multi-platform solution I'd advocate for using LLVM's libcxx or option #2.

@Mark-Simulacrum
Copy link
Member

AFAIK only the x86_64-unknown-linux-gnu target on master today has LLVM built as a dylib (everything else statically links it). I believe we determined that a static link doesn't have this problem so we don't currently need to do this elsewhere?

@Mark-Simulacrum
Copy link
Member

@bors try

@bors
Copy link
Contributor

bors commented Nov 11, 2020

⌛ Trying commit d2ad472 with merge 7190d347441d18c5139f2301983961b062af5aa1...

@jethrogb
Copy link
Contributor Author

For testing, need to run nm or objdump on the final artifacts. What we be a good place to insert such a test?

@Mark-Simulacrum
Copy link
Member

Hm, it's hard -- we don't run tests on dist builders usually. I guess we could start a new testsuite for dist builders.

cc @pietroalbini on dist tests

@jethrogb
Copy link
Contributor Author

AFAIK only the x86_64-unknown-linux-gnu target on master today has LLVM built as a dylib (everything else statically links it).

I think the llvm.link_shared config.toml option controls this, but I can't find that it's set to true anywhere for the Linux dist builder?

@Mark-Simulacrum
Copy link
Member

ThinLTO, set https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile#L98, implies shared linking currently.

@bors
Copy link
Contributor

bors commented Nov 11, 2020

☀️ Try build successful - checks-actions
Build commit: 7190d347441d18c5139f2301983961b062af5aa1 (7190d347441d18c5139f2301983961b062af5aa1)

@jethrogb
Copy link
Contributor Author

Confirmed that the try build doesn't reproduce https://github.com/Mark-Simulacrum/rust-issue-76980

@Mark-Simulacrum
Copy link
Member

Ok, sounds good. I'm going to go ahead and r+ this -- I think it's the right fix and I want to get nightly fixed -- we can figure out how to test it in a follow-up PR. Thinking a bit more, I think we can enable ThinLTO on one of the test builders and just add the nm commands as a run-make test -- does that sound plausible to you @jethrogb?

@bors r+

@bors
Copy link
Contributor

bors commented Nov 11, 2020

📌 Commit d2ad472 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 Nov 11, 2020
@Mark-Simulacrum
Copy link
Member

@bors rollup=never p=1

@jethrogb
Copy link
Contributor Author

I think we can enable ThinLTO on one of the test builders and just add the nm commands as a run-make test -- does that sound plausible to you @jethrogb?

I don't think so because I assume the test builders don't use our custom libstdc++? And I also want to guard against future changes in e.g. the Dockerfile/GCC upgrades messing up the dist build accidentally.

@Mark-Simulacrum
Copy link
Member

Right, I was saying that we would try to match the configuration on linux dist builder on a test builder.

@sami2020pro
Copy link

sami2020pro commented Nov 11, 2020 via email

@jethrogb
Copy link
Contributor Author

match the configuration on linux dist builder on a test builder.

Oh I see. I think that's a little more involved than just "enabling thinlto". We can try that, basically reusing the Dockerfile? I have a couple of concerns:

  • The dist builder uses a super old version of Debian. Would we be able to run the whole test suite?
  • The dist builder currently builds GCC and Clang prior to running x.py, that takes about an hour. Do we have room in our time budget for that?

@Mark-Simulacrum
Copy link
Member

GCC and clang builds are docker-cached, so they don't really affect our time budget that much. We bounce anyway when those get invalidated I believe.

It's a good question -- I'm not sure if we can run the whole test suite. Maybe a starting goal is to see if we can add e.g. x.py test src/tools/run-make to the current linux dist builder and leave it at that.

@bors
Copy link
Contributor

bors commented Nov 11, 2020

⌛ Testing commit d2ad472 with merge 5404efc...

@bors
Copy link
Contributor

bors commented Nov 11, 2020

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 11, 2020
@bors bors merged commit 5404efc into rust-lang:master Nov 11, 2020
@rustbot rustbot added this to the 1.49.0 milestone Nov 11, 2020
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.

Build hang on Linux
6 participants