aarch64 build fixes for 2.19.1

[dslarm]

This PR will get us going again on linux-aarch64

• remove previous python package id limits
• fix build issue in xla

Work in progress:

• Locally this reaches the end of the compilation phase (no C++ compile errors :0), but there's a wheels problem:

• a) it looks to me like it's trying to make x86_64 ones when doing aarch64 - although that does not error (surely it should.) - smells like it's from the bazel part of the build:

[17,433 / 17,437] Writing: bazel-out/aarch64-opt/bin/tensorflow/tools/lib_package/libtensorflow.tar.gz; 35s local ... (3 actions running)
[17,436 / 17,437] Action tensorflow/tools/pip_package/wheel_house/tensorflow-2.19.1-cp39-cp39-linux_x86_64.whl; 1s local
[17,436 / 17,437] Action tensorflow/tools/pip_package/wheel_house/tensorflow-2.19.1-cp39-cp39-linux_x86_64.whl; 10s local
[17,436 / 17,437] Action tensorflow/tools/pip_package/wheel_house/tensorflow-2.19.1-cp39-cp39-linux_x86_64.whl; 40s local
INFO: Elapsed time: 2038.825s, Critical Path: 275.04s
INFO: 17229 processes: 686 internal, 16543 local.

and

• b) it particularly doesn't like python 3.12:

Setting up cross-python
Finished setting up cross-python
++ /home/conda/feedstock_root/build_artifacts/tensorflow-split_1762861445005/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin/python -c 'import sys;print('\''.'\''.join(str(v) for v in sys.version_info[:2]))'
+ PY_VER=3.12
+ /home/conda/feedstock_root/build_artifacts/tensorflow-split_1762861445005/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin/python -m pip install --no-deps /home/conda/feedstock_root/build_artifacts/tensorflow-split_1762861445005/work/tensorflow_pkg/tensorflow-2.19.1-cp312-cp312-linux_x86_64.whl
ERROR: tensorflow-2.19.1-cp312-cp312-linux_x86_64.whl is not a supported wheel on this platform.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21003886856. Examine the logs at this URL for more detail.}

[dslarm]

also need to check this line from the build output:

WARNING (libtensorflow_cc): run-exports library package conda-forge/linux-aarch64::libstdcxx-ng==15.2.0=hf1166c9_7 in requirements/run but it is not used (i.e. it is overdepending or perhaps statically linked? If that is what you want then add it to `build/ignore_run_exports`)

• aarch64 builds are restricted to using gcc11 at the moment - so wasn't expecting to see 15.x.x

[h-vetinari]

also need to check this line from the build output:

This is fine. We always use the newest C++ standard library implementation, even if you compile with older compiler versions. That works because the standard libraries (libcxx and libstdcxx) are highly backwards compatible

[h-vetinari]

Same error as you noted in the OP already

+ PY_VER=3.12
+ $PREFIX/bin/python -m pip install --no-deps $SRC_DIR/tensorflow_pkg/tensorflow-2.19.1-cp312-cp312-linux_x86_64.whl
ERROR: tensorflow-2.19.1-cp312-cp312-linux_x86_64.whl is not a supported wheel on this platform.

This will probably require patching the bazel files

[dslarm]

Spent some time trying to get to bottom of bazel system and interaction with building the wheels. I could not see how the platforms// etc gets populated or an equivalent 'target' platform - but a simple (dirty) change of telling the python script that the target is arm64 resolved it.

Do any of the maintainers here know a better attribute/variable that would be the actual build target - my patch is simple but the build now completes successfully:

-    platform_tag = select({
-        "@platforms//cpu:aarch64": "arm64",
-        "@platforms//cpu:arm64": "arm64",
-        "@platforms//cpu:x86_64": "x86_64",
-        "@platforms//cpu:ppc": "ppc64le",
-    }),
+    platform_tag = "arm64",

(obviously this patch is conditional on being a linux-aarch64 build..)

[dslarm]

Spent some time trying to get to bottom of bazel system and interaction with building the wheels. I could not see how the platforms// etc gets populated or an equivalent 'target' platform - but a simple (dirty) change of telling the python script that the target is arm64 resolved it.

The docs suggest that '@platforms//cpu' is supposed to be the result of bazel --cpu .. - in our case, the target cpu (aarch64), so why that's not the case in practice, I don't know.

[dslarm]

@conda-forge-admin, please rerender

[dslarm]

@conda-forge-admin, please rerender

[dslarm]

@h-vetinari - can you take a look at this. I think it's ready for review - it doesn't build in the CI (timeouts?) but does build locally- which is pretty much normal for me with this feedstock.

[h-vetinari]

Hey @dslarm! We wanted to get #470 out the door first, but now that this is in, you can either merge or rebase this PR, and then I'll gladly take a look at it and start the CI job for it.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[dslarm]

Thanks - roger that, I'm on it.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21560039270. Examine the logs at this URL for more detail.}

[dslarm]

uh oh.

  - nothing provides __cuda needed by tensorflow-base-2.19.1-cuda128py310h9f74bc1_200

Could not solve for environment specs
The following packages are incompatible
├─ icu =78.2 h33c6efd_0 is requested and can be installed;
└─ tensorflow-base >=2.19.1,<3.0a0 * is not installable because there are no viable options
   ├─ tensorflow-base 2.19.1 would require
   │  └─ icu >=75.1,<76.0a0 *, which conflicts with any installable versions previously reported;
   └─ tensorflow-base 2.19.1 would require
      └─ __cuda =* *, which is missing on the system.
Traceback (most recent call last):

and yet this build is supposed to not be cuda.
I swear this built this morning..

[dslarm]

hmm, bit more of the cut n paste context:

conda_libmamba_solver.conda_build_exceptions.ExplainedDependencyNeedsBuildingError: Unsatisfiable dependencies for platform linux-64: {MatchSpec("tensorflow-base==2.19.1=cuda128py310h9f74bc1_200"), MatchSpec("__cuda")}
Encountered problems while solving:
  - nothing provides __cuda needed by tensorflow-base-2.19.1-cuda128py310h9f74bc1_200

well, it's trying to install linux-64 .. that's not right!

hmm - so that's the host (build platform) - and it looks like it actually is just that the icu78-compatible tensorflows have not been built yet - which were committed this morning. I'll wait!

[dslarm]

@h-vetinari - OK, it's good now for your review - the icu 78 builds are live - the aarch64 build completes just fine, and I checked one of the CUDA x86 builds - that also worked.

[h-vetinari]

Nice job on fixing the aarch build! Next stop aarch+CUDA? 🙃

I'm going to merge this with the skip, because we don't need to rebuild the x64 packages here.