Constraints on GLIBC version

[kventinel]

Description of the feature request:

Some times I need some contraints on GLIBC version for cross-platforms build, but currently I think it's impossible to make.

What underlying problem are you trying to solve with this feature?

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

Given that you can add any constraints you want to a custom platform, would you like the auto-generated host platform to contain a constraint for the glibc version of the host?

If that is the case, the most maintainable solution would probably be to implement #8766 and then have someone provide this functionality via a Bzlmod module. In this way, Bazel itself wouldn't need to maintain logic to detect glibc versions and the community could contribute to it more easily.

@kventinel Would this cover your needs?

[Wyverald]

I don't think it should be built into Bazel; what @fmeum said could work.

Adding @katre @gregestren for opinions; on the external deps team's side, I think we would probably just close this.

[katre]

Agreed.

[kventinel]

@kventinel Would this cover your needs?

Probably not. I want to build tensorflow but change compiler version (or some constrain for compiler) to use glibc not greater than 2.25, because of constraints on cross-compile device.

[fmeum]

That seems possible to do with what Bazel provides today:

1. Define a new constraint setting for glibc versions.
2. Define cross-compiling toolchains with the required glibc version as target constraint values.
3. Define the platforms you want to build for and let Bazel select the matching toolchain based on the constraints.

Step 2 is probably quite a bit of work, but I don't think Bazel could help much with it.

@kventinel Is this going into the right direction? What exactly do you think Bazel should help you with that it can't do today?

[katre]

Is glibc version really a fundamental constraint for a platform? Can a single machine ever have multiple glibc versions? Is it possible to build code that would run properly on machines with different glibc versions?

[katre]

Also, just to note: constraint values are good for binary features, or enum-style features, but a bad fit for numeric data (like version numbers). Would a build setting be better suited here? You can also use build settings to choose toolchains (using the target_settings attribute on toolchain, yes I'm behind on my post-BazelCon doc-writing).

[fmeum]

Also, just to note: constraint values are good for binary features, or enum-style features, but a bad fit for numeric data (like version numbers). Would a build setting be better suited here? You can also use build settings to choose toolchains (using the target_settings attribute on toolchain, yes I'm behind on my post-BazelCon doc-writing).

Just want to ask because I've been curious about this for a while: Why are build settings better for numeric features when it comes to toolchain selection? Don't target_compatible_with and target_settings have in common that they only admit a single value for any given "dimension" (constraint_setting or build setting) instead of accepting a range? Build settings don't require defining a constraint value, but is that the only reason?

[katre]

For toolchain resolution specifically, you're right: you can't write a constraint_value or a config_setting that checks version ranges. However, for other uses, you can absolutely write a custom build setting rule that checks a version range, and that's much cleaner.

I have a dream of someday opening up the config setting system to allow custom drop-in replacements for config_setting, so that something like this would work, but right now it's just an idea and I worry that the design would either be too complex or too error prone.