Feature #21929: Add configure script options for instrumenting Rust builds

• Status: Open
• Assignee: -
• Target version: -

[jprokop (Jarek Prokop)]

Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT.

Rust is a compiled language with various compile flags at various stages and approaches.

My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions
can be fully and easily compliant with their guidelines on compilation flags.

Currently, for production build of Ruby, rustc tool is used, which is instrumented differently from cargo in debug builds.

In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695
I have focused on providing rustc with our distribution flags, during the PR
it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764
that should be present even when providing distribution flags.

This is not too different from C, as there are also security flags,
such as configure script enabling the arm64's BTI and PAC when possible.

rustc of version 1.92, at the time of the PR uses the last mention of a flag.

Ideally rustc would know RUSTFLAGS, but as far as I can tell, the enviroment variable only affects cargo.

In Fedora the current guidance recommends using %build_rustflags https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_flags
which expands to -Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn

The best result is each part of Rust in Ruby would receive the flags defined during configure time.

In cases where complication flags should conflict, in Fedora distribution flags take precedence:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_with_cargo_internally

[mame (Yusuke Endoh)]

@alanwu (Alan Wu) Can we close this? https://github.com/ruby/ruby/pull/15695 is already merged.

[alanwu (Alan Wu)]

• Status changed from Open to Feedback

It's hard for me to tell what's desired beyond the already merged PR you proposed. It seems to be about some mechanism for flag overriding for development builds that use cargo, but sort of by definition packaging is not a great fit for development because the code is changing all the time.

A debug build that uses only rustc is already possible using the mechanism in the merged PR.

[jprokop (Jarek Prokop)]

While the MR allows to provide the flags in some manner, which is certainly a big part, in the PR there were mentioned some flags that are important to upstream to keep. See comment https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 , I see parallel here to for example setting the security-related branch protection flags for ARM architecture builds (or -fstack-protector, or other ...) https://github.com/ruby/ruby/blob/master/configure.ac#L915 .

Currently, for Rust, all flag "groups": debug, security, and optimization are in a single variable.

To continue with the branch-protection flag parallel as an example of a security-related compilation flag, that flag is set more or less unconditionally, as far as I can tell there isn't an easy way to disable it, and the CFLAGS can be freely overriden, as the branch-protection flag is appended if the example program compiles with the flag, no matter what was specified in CFLAGS.

I'd maybe ask,
would it make sense to split the single variable into multiple, make parts of it overridable and append the important flags like the -C overflow-checks=on unconditionally?

If there would be such split, if program can be compiled with a flag, like the -C overflow-checks=on, it could always end up in the rustc compilation flag string, no matter what was specified on ./configure step.

This could allow more complete overriding of the rest of the flags (such as -g, -C lto=thin, ...), and using a dedicated ENV variable for the Rust flags as well (somthing similar to CFLAGS="...") in addition to the existing configure flags, if the important flags are appended when for example the compilation test program can be successfully compiled.

IOW, I feel like the current approach, despite being sufficient for, could be expanded further, to ensure more general and optimization flags can be fully overriden and to ensure that the important flags are always present.

[alanwu (Alan Wu)]

• Status changed from Feedback to Open