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

[bootstrap] Add gcc to dist generation #125419

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented May 22, 2024

As @eholk summarized below:

From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use.

It'll greatly improve the experience for anyone wanting to work on the GCC backend from the compiler.

Should help with #124172.
Will unblock #124353.

r? @Kobzol

@rustbot
Copy link
Collaborator

rustbot commented May 22, 2024

⚠️ Warning ⚠️

  • These commits modify submodules.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels May 22, 2024
@rustbot
Copy link
Collaborator

rustbot commented May 22, 2024

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the A-testsuite Area: The testsuite used to check the correctness of rustc label May 23, 2024
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the A-meta Area: Issues about the rust-lang/rust repository. label May 23, 2024
@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez
Copy link
Member Author

From what I can see, it's not possible to tell reuse to allow deprecated licenses. So in this case, I have no clue how we can go around this issue. If someone has an idea?

@Kobzol
Copy link
Contributor

Kobzol commented May 23, 2024

@davidtwco Any suggestions on what to do about the GPL-2.0 license of GCC?

@davidtwco
Copy link
Member

@davidtwco Any suggestions on what to do about the GPL-2.0 license of GCC?

Will get back to you about this

@davidtwco
Copy link
Member

@wesleywiser and I discussed this and we're not sure about how to get REUSE to play ball (@pietroalbini might know), but we've forwarded this on to t-compiler's council rep to double-check that adding gcc like this is okay, license-wise.

@pietroalbini
Copy link
Member

From what I can see, it's not possible to tell reuse to allow deprecated licenses. So in this case, I have no clue how we can go around this issue. If someone has an idea?

Note that REUSE doesn't mark the GPL 2.0 license as deprecated. What is deprecated is referring to it as GPL-2.0. You should refer to the license as either GPL-2.0-only or GPL-2.0-or-later, depending on what is appropriate.

Also, the warning doesn't come from REUSE itself, but from the SPDX License List (you'll find GPL-2.0 as deprecated in there).

@eholk
Copy link
Contributor

eholk commented Jun 7, 2024

We discussed this at the Council meeting today and we don't have any concerns with this change. However, we would like to confirm with the Foundation. @abibroom - do you know of any concerns from the Foundation side (feel free to ping me on Zulip or reach out via email if you'd rather not discuss this publicly.

From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use.

@Kobzol
Copy link
Contributor

Kobzol commented Jun 9, 2024

@bors try

Just to see what happens on Linux dist.

@@ -2365,6 +2366,10 @@ impl Step for RustDev {
// just broadly useful to be able to link against the bundled LLVM.
tarball.add_dir(builder.llvm_out(target).join("include"), "include");

tarball.add_dir(builder.gcc_out(target).join("install/lib/libgccjit.so"), "libgccjit.so");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What will this do on Windows? 🤔 Does the gcc build also work on non-Linux OSes, in general?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it doesn't, good catch!

@bors
Copy link
Contributor

bors commented Jun 9, 2024

⌛ Trying commit f302cfd with merge 9e6f6bf...

bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 9, 2024
[bootstrap] Add gcc to dist generation

As `@eholk` summarized below:

> From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use.

It'll greatly improve the experience for anyone wanting to work on the GCC backend from the compiler.

Should help with rust-lang#124172.
Will unblock rust-lang#124353.

r? `@Kobzol`
@nikic
Copy link
Contributor

nikic commented Jun 9, 2024

Can this be done without adding gcc as a submodule?

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Jun 9, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 9, 2024
@abibroom
Copy link

We discussed this at the Council meeting today and we don't have any concerns with this change. However, we would like to confirm with the Foundation. @abibroom - do you know of any concerns from the Foundation side (feel free to ping me on Zulip or reach out via email if you'd rather not discuss this publicly.

I'd like to be able to say this is all fine, but want to run it past Foundation legal counsel first just to make sure. Please bear with me whilst that happens!

@abibroom
Copy link

We discussed this at the Council meeting today and we don't have any concerns with this change. However, we would like to confirm with the Foundation. @abibroom - do you know of any concerns from the Foundation side (feel free to ping me on Zulip or reach out via email if you'd rather not discuss this publicly.

I'd like to be able to say this is all fine, but want to run it past Foundation legal counsel first just to make sure. Please bear with me whilst that happens!

We should be good to go with this. Legal raised two points, neither of which I believe to be blocking concerns:

  1. Compliance with the GPLv2 license, specifically, the requirement to provide source code as well as binary distributions. This has hopefully already been thoroughly considered before deciding to add the component.

  2. Enabling downstream compliance: "When it comes to downstream distribution, anyone providing a binary distribution of Rust incorporating this component will need to provide source code for the whole distribution. This is ultimately their problem, but if you're aware of anyone who's doing this currently, it's probably worth talking through those cases and figuring out how to provide notice to them and other potential distributors of their additional obligations with respect to this component."

@eholk
Copy link
Contributor

eholk commented Jun 14, 2024

Enabling downstream compliance: "When it comes to downstream distribution, anyone providing a binary distribution of Rust incorporating this component will need to provide source code for the whole distribution. This is ultimately their problem, but if you're aware of anyone who's doing this currently, it's probably worth talking through those cases and figuring out how to provide notice to them and other potential distributors of their additional obligations with respect to this component."

@abibroom - just to make sure, if someone wanted to make a downstream binary distribution without releasing source code (which strikes me as rather unlikely), they could still do so if they chose not to include the libgccjit component?

I want to make sure this change doesn't effectively mean we have to relicense Rust as GPL2.

@bjorn3
Copy link
Member

bjorn3 commented Jul 12, 2024

Assuming that cg_gcc does the same for distribution as cg_clif, all GCC components and the GCC backend itself will end up in a rustc-codegen-gcc-preview component which would need to be separately installed (using eg rustup component add rustc-codegen-gcc-preview) to use the GCC backend.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@GuillaumeGomez
Copy link
Member Author

From what I can see, it's not possible to tell reuse to allow deprecated licenses. So in this case, I have no clue how we can go around this issue. If someone has an idea?

Note that REUSE doesn't mark the GPL 2.0 license as deprecated. What is deprecated is referring to it as GPL-2.0. You should refer to the license as either GPL-2.0-only or GPL-2.0-or-later, depending on what is appropriate.

Also, the warning doesn't come from REUSE itself, but from the SPDX License List (you'll find GPL-2.0 as deprecated in there).

As you can see @pietroalbini, REUSE wants GPL-2.0 specifically, any other will not work. And SPDX is considering GPL-2.0 as deprecated. So unless I'm missing something, we're stuck here. Any idea?

@Skgland
Copy link
Contributor

Skgland commented Jul 22, 2024

Based on #125419 (comment) it looks like the deprecated license originates in three files

'GPL-2.0' found in:

  • ../src/gcc/gcc/testsuite/c-c++-common/analyzer/asm-x86-dyndbg-2.c
  • ../src/gcc/gcc/testsuite/c-c++-common/analyzer/taint-assert-BUG_ON.c
  • ../src/gcc/gcc/testsuite/gcc.dg/analyzer/asm-x86-dyndbg-1.c

would it be possible to patch these to specify GPL-2.0-only or GPL-2.0-or-later instead of GPL-2.0?

All three currently contain:

/* Adapted from code in the Linux kernel, which has this: */
/* SPDX-License-Identifier: GPL-2.0 */

@GuillaumeGomez
Copy link
Member Author

GuillaumeGomez commented Jul 22, 2024

I'll simply remove them...

EDIT: Ah since it's our fork, I suppose it's ok to change the license there.

@Skgland
Copy link
Contributor

Skgland commented Jul 22, 2024

Based on https://github.com/torvalds/linux/blob/master/LICENSES/preferred/GPL-2.0

For 'GNU General Public License (GPL) version 2 only' use:
    SPDX-License-Identifier: GPL-2.0
  or
    SPDX-License-Identifier: GPL-2.0-only

and the comment mentioning that the license is chosen based on them being derived from Linux kernel files with GPL-2.0 I think GPL-2.0-only should be considered equivalent

@davidmalcolm
Copy link

As @eholk summarized below:

From my understanding, this change would add libgccjit as an optional component to the Rust distribution. This library is licensed under GPLv2 and currently we do not have any other components under that license so it would be a new license, and one that is generally more restrictive than the other licenses we use.

Note that the libgccjit library is licensed under GPLv3, not GPLv2 (I'm the author/maintainer of libgccjit, but it's mostly just a thin wrapper around GCC's own code hence GPLv3).

Are you basing the GPLv2 thing on those SPDX identifiers from the three files in the testsuite? Those are taken/adapted from the Linux kernel and thus GPLv2 only, AIUI.

@GuillaumeGomez
Copy link
Member Author

That's what I inferred as well: rust-lang/gcc#61

@GuillaumeGomez
Copy link
Member Author

I think I fixed all issues here. Is there anything else that remains to be done?

@nikic
Copy link
Contributor

nikic commented Jul 22, 2024

I'd like to repeat this question:

Can this be done without adding gcc as a submodule?

Does distributing libgcc require gcc to be an actual submodule in the rust repo?

Does this make gcc part of the rustc-src tarballs?

@GuillaumeGomez
Copy link
Member Author

I'd like to repeat this question:

Can this be done without adding gcc as a submodule?

Does distributing libgcc require gcc to be an actual submodule in the rust repo?

Does this make gcc part of the rustc-src tarballs?

I originally went for a commit hash stored in a file but I was asked (at least that's what I remember but maybe I'm wrong) to use a git submodule instead to make things simpler.

Does this make gcc part of the rustc-src tarballs?

Normally no but we'll need someone from infra to answer this question.

@Kobzol
Copy link
Contributor

Kobzol commented Jul 22, 2024

Does this make gcc part of the rustc-src tarballs?

Yes, because the submodule is under the src directory, and everything there is included by default.

As of the current shape of this PR, there is src/gcc with all its GCC glory in our source tarballs.

Edit: you can try this locally using x dist rustc-src.

@GuillaumeGomez
Copy link
Member Author

Thanks for clarifying @Kobzol !

So what remains to be discussed here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues about the rust-lang/rust repository. A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet