Hello,
I've run across a strange problem building a package that has some rust files in it. The build goes fine until the end when it starts to check for shebangs. It ends like this:
/usr/src/debug/suricata-7.0.3-1.fc41.x86_64/rust/vendor/alloc-no-stdlib/src/ lib.rs has shebang which doesn't start with '/' ([no_std])
When I check the file, I find this: #![no_std]
#[macro_use] mod allocated_memory; mod stack_allocator; mod allocated_stack_memory;
Not being a rust programmer, I have no good idea what the code is doing. I can't patch this code to move it off the first line because it's vendored code.
Is there a way to tell rpmbuild not to worry about this?
-Steve
On Mon, Feb 26, 2024, 22:25 Steve Grubb sgrubb@redhat.com wrote:
Hello,
I've run across a strange problem building a package that has some rust files in it. The build goes fine until the end when it starts to check for shebangs. It ends like this:
/usr/src/debug/suricata-7.0.3-1.fc41.x86_64/rust/vendor/alloc-no-stdlib/src/ lib.rs has shebang which doesn't start with '/' ([no_std])
When I check the file, I find this: #![no_std]
#[macro_use] mod allocated_memory; mod stack_allocator; mod allocated_stack_memory;
Not being a rust programmer, I have no good idea what the code is doing. I can't patch this code to move it off the first line because it's vendored code.
Is there a way to tell rpmbuild not to worry about this?
The solution should be simple - remove stray +x permissions from all *.rs files.
Some editors see a file that starts with "#!" and think "hey, this looks like a script! let me mark the file as executable!" even though this is Rust syntax for global attributes, not a shebang.
Fabio
-Steve
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hello,
On Monday, February 26, 2024 4:38:35 PM EST Fabio Valentini wrote:
I've run across a strange problem building a package that has some rust files in it. The build goes fine until the end when it starts to check for shebangs. It ends like this:
/usr/src/debug/suricata-7.0.3-1.fc41.x86_64/rust/vendor/alloc-no-stdlib/s rc/ lib.rs has shebang which doesn't start with '/' ([no_std])
When I check the file, I find this: #![no_std]
#[macro_use] mod allocated_memory; mod stack_allocator; mod allocated_stack_memory;
Not being a rust programmer, I have no good idea what the code is doing. I can't patch this code to move it off the first line because it's vendored code.
Is there a way to tell rpmbuild not to worry about this?
The solution should be simple - remove stray +x permissions from all *.rs files.
Thanks. That did it.
-Steve
On Mon, Feb 26, 2024 at 04:25:02PM -0500, Steve Grubb wrote:
Hello,
I've run across a strange problem building a package that has some rust files in it. The build goes fine until the end when it starts to check for shebangs. It ends like this:
/usr/src/debug/suricata-7.0.3-1.fc41.x86_64/rust/vendor/alloc-no-stdlib/src/ lib.rs has shebang which doesn't start with '/' ([no_std])
When I check the file, I find this: #![no_std]
#[macro_use] mod allocated_memory; mod stack_allocator; mod allocated_stack_memory;
Not being a rust programmer, I have no good idea what the code is doing. I can't patch this code to move it off the first line because it's vendored code.
The code is correct (for Rust) as it indicates that the standard library shouldn't be used:
https://docs.rust-embedded.org/book/intro/no-std.html
It's a bit unfortunate that Rust used the shebang syntax here, although in practice they couldn't be confused as these files shouldn't ever be executable.
It's also correct that RPM worries about this file since it is installed (in debuginfo) and appears to contain a shebang.
Is there a way to tell rpmbuild not to worry about this?
rust.spec has this in %prep, and /usr/lib/rpm/redhat/brp-mangle-shebangs only seems to care about executable files, so this should help:
# Sometimes Rust sources start with #![...] attributes, and "smart" editors think # it's a shebang and make them executable. Then brp-mangle-shebangs gets upset... find -name '*.rs' -type f -perm /111 -exec chmod -v -x '{}' '+'
Rich.
On 2/26/24 1:41 PM, Richard W.M. Jones wrote:
It's a bit unfortunate that Rust used the shebang syntax here, although in practice they couldn't be confused as these files shouldn't ever be executable.
It's _possible_ to play comment tricks for executable rust scripts, because rustc allows and ignores actual shebang lines.
#!/bin/bash -e #![cfg(unix)] /* (any attribute as a shell comment) # shell here to self-compile rustc "$0" -o ./foo exec ./foo "$@" (end rust comment) */ // continue in rust here fn main() { ... }
There is also a real "cargo script" feature in development: https://github.com/rust-lang/cargo/issues/12207
It's also correct that RPM worries about this file since it is installed (in debuginfo) and appears to contain a shebang.
Is there a way to tell rpmbuild not to worry about this?
rust.spec has this in %prep, and /usr/lib/rpm/redhat/brp-mangle-shebangs only seems to care about executable files, so this should help:
# Sometimes Rust sources start with #![...] attributes, and "smart" editors think # it's a shebang and make them executable. Then brp-mangle-shebangs gets upset... find -name '*.rs' -type f -perm /111 -exec chmod -v -x '{}' '+'
I may have to make that smarter if "cargo script" gets used.
For now though, clearing everything should be fine.
https://doc.rust-lang.org/reference/attributes.html If I understand this page of The Rust Reference correctly, then moving the #![no_std] attribute from the first line of the file shouldn't break anything. So you can try side-stepping the issue by patching the file and adding "// lol pointless comment" at the top.
A.FI.
-
Artur Frenszek-Iwicki -
Fabio Valentini -
Josh Stone -
Richard W.M. Jones -
Steve Grubb