Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable cross compiling for POWER architecture #47

Merged
merged 6 commits into from
Nov 29, 2021

Conversation

carterbox
Copy link
Member

@carterbox carterbox commented Nov 17, 2021

We suspect that the emulated (as opposed to native) builds may be causing the tests to fail for these architectures. This commit tries to bump the conda-forge builds back to native hosts instead of cross-compiling.

Closes PyWavelets/pywt#607

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.

We suspect that the emulated (as opposed to native) builds may be causing the tests to fail for these architectures. This commit tries to bump the conda-forge builds back to native hosts instead of cross-compiling.

PyWavelets/pywt#607
@conda-forge-linter
Copy link

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) and found it was in an excellent condition.

@carterbox
Copy link
Member Author

@conda-forge-admin, please rerender

@jakirkham
Copy link
Member

jakirkham commented Nov 17, 2021

ARM can't be moved ( conda-forge/conda-forge.github.io#1555 )

Edit: Though we already have it configured to emulate anyways.

In theory, setting a provider for osx_arm64 should cause that
architecture to be built, but due to the drone.io outage we need
to force cross-compilation on another platform. We also need to
force compilation of linux_ppc64le natively because tests fail
when emulated.
@carterbox
Copy link
Member Author

Looks like cross-compiling was the problem! Will mark ready for review once all the builds are green.

@carterbox carterbox changed the title Try to disable cross compiling for ARM and POWER Disable cross compiling for POWER architecture Nov 17, 2021
conda-forge.yml Outdated
linux_aarch64: linux_64
linux_ppc64le: linux_64
osx_arm64: osx_64
linux_ppc64le: linux_ppc64le # tests fail when emulating power from x86
Copy link
Member

@jakirkham jakirkham Nov 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think this can just be default since we build natively there

Suggested change
linux_ppc64le: linux_ppc64le # tests fail when emulating power from x86

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I explicitly choose linux_ppc64le because we know that the build doesn't work when emulated. The default could be changed to linux_64 like it was for linux_aarch64, then this build would break again.

Copy link
Member Author

@carterbox carterbox Nov 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, It only renders with linux_ppc64le. I cannot use the default key here; it causes the following error:

  File "/home/dching/miniconda3/envs/forge/lib/python3.9/site-packages/conda_smithy/configure_feedstock.py", line 947, in _get_platforms_of_provider
    build_platform, build_arch = build_platform_arch.split("_")
ValueError: not enough values to unpack (expected 2, got 1)

Seems like the build platform is expected to be an explicit platform if defined.

conda-forge.yml Outdated Show resolved Hide resolved
conda-forge.yml Outdated Show resolved Hide resolved
@carterbox
Copy link
Member Author

These linux ARM builds have been running for more than 2.5 hours! 😟

conda-forge.yml Outdated
osx_arm64: osx_64
conda_forge_output_validation: true
provider:
linux_aarch64: default
linux_aarch64: travis
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no ARM support on Travis. We are stuck emulating them on Azure. Yes it does take a while unfortunately.

Please see PR ( conda-forge/conda-forge.github.io#1555 )

@rgommers
Copy link
Contributor

LGTM, happy if it works!

Random question: PRs on feedstocks are always a pain to review, because the regular diff view is mostly changes from re-rendering. Is there any guidance or best practice around this, like one should be squashing history to 1-2 commits with changes, and one re-rendering commit? And then one can review the commit diff?

@grlee77
Copy link
Member

grlee77 commented Nov 18, 2021

Usually I just click on the commits tab to see the non-rerendering ones individually. In most cases there are only a small number, so that works out okay.

@carterbox
Copy link
Member Author

I believe only the files in the recipe folder and conda-forge.yml control the rendering (are managed by humans or bots), so I look at those.

@isuruf
Copy link
Member

isuruf commented Nov 18, 2021

Btw, can you check if using blas=*=*netlib fix the cross compiling issue. I think it's because of openblas using some system calls not supported by qemu.

@jakirkham
Copy link
Member

We hide some files with .gitattributes. Would ignore those. There's always a delicate balance around what to hide and what to include.

@jakirkham
Copy link
Member

Btw, can you check if using blas=*=*netlib fix the cross compiling issue. I think it's because of openblas using some system calls not supported by qemu.

This is a really good point!

Have seen similar things with VMs (like VirtualBox) where AVX and some versions of SSE instructions don't work. Though normally in that case different kernels without those instructions get selected as OpenBLAS determines they are not supported.

What system calls did you have in mind?

@isuruf
Copy link
Member

isuruf commented Nov 18, 2021

mbind

carterbox added a commit to carterbox/pywavelets-feedstock that referenced this pull request Nov 23, 2021
Maybe emulated builds of ppc64le are failing because the BLAS
implemenation doesn't support emulation.

conda-forge#47 (comment)
@carterbox
Copy link
Member Author

Adding blas=*=*netlib to the test requirements did not work.

@erykoff
Copy link

erykoff commented Nov 29, 2021

FYI, I believe this PR is preventing the scikit-image python 3.10 migration.

@erykoff
Copy link

erykoff commented Nov 29, 2021

Or rather, merging this PR will unblock the scikit-image python 3.10 migration.

Copy link
Contributor

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for merging. Can this be squash-merged, or is it needed/useful to rewrite into a single commit with functional changes and one other commit to re-render?

@jakirkham
Copy link
Member

It's useful to see the commits from re-rendering on the non-recipe files in case there is an issue we need to dig into later

@beckermr
Copy link
Member

I agree w/ @jakirkham but there is no reason to change things now. Let's go ahead and merge.

@jakirkham jakirkham merged commit caef6b6 into conda-forge:master Nov 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Package seems broken on ppc64le
8 participants