rpmbuild problem with rust code

[Steve Grubb]

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

[Fabio Valentini]

On Mon, Feb 26, 2024, 22:25 Steve Grubb <sgrubb(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Steve Grubb]

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

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Josh Stone]

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.

[Artur Frenszek-Iwicki]

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.