Currently rust on arm fails to compile due to '-mno-fdpic'. This flag disables a GCC feature that we don't want for kernel builds, so let's skip it.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38...
Signed-off-by: Miguel Ojeda ojeda@kernel.org
Tested-by: Naresh Kamboju naresh.kamboju@linaro.org Signed-off-by: Naresh Kamboju naresh.kamboju@linaro.org
Tested-by: Rudraksha Gupta guptarud@gmail.com Signed-off-by: Rudraksha Gupta guptarud@gmail.com --- Currently rust on arm fails to compile due to '-mno-fdpic'. This flag disables a GCC feature that we don't want for kernel builds, so let's skip it.
It seems like this bug went through the cracks, so I went ahead and sent it. Hopefully nobody minds.
Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38... --- rust/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rust/Makefile b/rust/Makefile index 3aca903a7d08..f207ba0ed466 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -273,7 +273,7 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \ -fzero-call-used-regs=% -fno-stack-clash-protection \ -fno-inline-functions-called-once -fsanitize=bounds-strict \ -fstrict-flex-arrays=% -fmin-function-alignment=% \ - -fzero-init-padding-bits=% \ + -fzero-init-padding-bits=% -mno-fdpic \ --param=% --param asan-%
# Derived from `scripts/Makefile.clang`.
--- base-commit: a5806cd506af5a7c19bcd596e4708b5c464bfd21 change-id: 20250520-rust-mno-fdpic-arm-fix-940a58bf9433
Best regards,
On Wed, May 21, 2025 at 12:48 AM Rudraksha Gupta guptarud@gmail.com wrote:
Currently rust on arm fails to compile due to '-mno-fdpic'. This flag disables a GCC feature that we don't want for kernel builds, so let's skip it.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org Closes: https://lore.kernel.org/all/CA+G9fYvOanQBYXKSg7C6EU30k8sTRC0JRPJXYu7wWK51w38...
Signed-off-by: Miguel Ojeda ojeda@kernel.org
Tested-by: Naresh Kamboju naresh.kamboju@linaro.org Signed-off-by: Naresh Kamboju naresh.kamboju@linaro.org
Thanks for the patch!
A few quick notes -- I hope these help to explain how it usually woks, given what you said in the other thread:
- Since you asked: in general, Linus does not take patches. Normally, patches go through some relevant tree, and then then eventually sent to Linus. In this case, the Rust tree would typically be the one taking this patch. Please see the `MAINTAINERS` file.
- You cannot generally send a patch in the name of someone else unless they provided their Signed-off-by. Here, neither I nor Naresh provided the Signed-off-by as far as I know. Please be careful with that! Please read the DCO and the rest of the Submitting Patches file: https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-d...
- Similarly, in general, you should be careful about adding tags from someone else unless they provided them or there was an understanding they meant to provide it (e.g. Tested-by). Please see the "Tagging people requires permission" section in the same file: https://docs.kernel.org/process/submitting-patches.html#tagging-people-requi....
- The chain of SoBs has a particular meaning. For instance, this patch would mean (as written) that I wrote the patch, and that then Naresh carried it, and then you carried it. And if I had written the patch, then the Git author should have been me ("From:" would have been added by Git). I guess you may have meant to indicate there were several contributors -- that is typically done with e.g. Co-developed-by or Suggested-by, depending on how they contributed.
- There is some repeated text in the non-commit message part of the email. Also, tags are written without empty lines between them.
- Ideally, fixes for build errors contain the main part of the build error message in the commit text so that it is easy to match it later on.
What I would have suggested to do in this situation is to ping in the other thread with a normal email (similar to the one you sent), asking if Naresh or someone else was going to send it, and mention that otherwise you are willing to do so (under yours or perhaps Naresh's name).
I hope this helps!
Cheers, Miguel
Thanks for the patch!
A few quick notes -- I hope these help to explain how it usually woks, given what you said in the other thread:
- Since you asked: in general, Linus does not take patches.
Normally, patches go through some relevant tree, and then then eventually sent to Linus. In this case, the Rust tree would typically be the one taking this patch. Please see the `MAINTAINERS` file.
Hello Miguel,
Oh gotcha, yeah b4 inputted the correct To: and CC:, I just moved that all to CC: and directed the patch to Linus since this was a bug fix. It seems the regular flow still applies. Sorry about that!
- You cannot generally send a patch in the name of someone else
unless they provided their Signed-off-by. Here, neither I nor Naresh provided the Signed-off-by as far as I know. Please be careful with that! Please read the DCO and the rest of the Submitting Patches file: https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-d...
- Similarly, in general, you should be careful about adding tags
from someone else unless they provided them or there was an understanding they meant to provide it (e.g. Tested-by). Please see the "Tagging people requires permission" section in the same file: https://docs.kernel.org/process/submitting-patches.html#tagging-people-requi....
- The chain of SoBs has a particular meaning. For instance, this
patch would mean (as written) that I wrote the patch, and that then Naresh carried it, and then you carried it. And if I had written the patch, then the Git author should have been me ("From:" would have been added by Git). I guess you may have meant to indicate there were several contributors -- that is typically done with e.g. Co-developed-by or Suggested-by, depending on how they contributed.
Whoops! I didn't realize that's what that meant, was just wanting to give you both credit for that. Thanks!
- There is some repeated text in the non-commit message part of the
email. Also, tags are written without empty lines between them.
Ah, I see. Usually b4 likes doing a cover letter, and for single patches it appends that in the commit itself. I'll keep that in mind moving forward. And thanks for letting me know about the tags! It seems like b4 generated that, so I'll manually separate that from now on
- Ideally, fixes for build errors contain the main part of the build
error message in the commit text so that it is easy to match it later on.
Ah gotcha, I'll keep that in mind!
What I would have suggested to do in this situation is to ping in the other thread with a normal email (similar to the one you sent), asking if Naresh or someone else was going to send it, and mention that otherwise you are willing to do so (under yours or perhaps Naresh's name).
I hope this helps!
This does, thanks! I'll drop this patch for now then and will assume that Naresh will eventually send it. I was hoping to get this in by the stable release that is set to happen during the weekend (doesn't excuse my sloppiness though, sorry about that once again)
Anyways, thanks for being patient with me as I learn. :)
Thanks,
Rudraksha
Cheers, Miguel
On Wed, May 21, 2025 at 3:57 PM Rudraksha Gupta guptarud@gmail.com wrote:
This does, thanks! I'll drop this patch for now then and will assume that Naresh will eventually send it. I was hoping to get this in by the stable release that is set to happen during the weekend (doesn't excuse my sloppiness though, sorry about that once again)
Anyways, thanks for being patient with me as I learn. :)
You're welcome! :)
Let's see if Naresh says something; otherwise, I think it is OK to send it under your SoB after a few days (acknowledging the diff from Naresh).
Thanks!
Cheers, Miguel
-
Miguel Ojeda -
Rudraksha Gupta