ARM OSX Migrator

[regro-cf-autotick-bot]

This feedstock is being rebuilt as part of the ARM OSX migration.

Feel free to merge the PR if CI is all green, but please don't close it without reaching out the the ARM OSX team first at @conda-forge/help-osx-arm64.

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. If you would like a local version of this bot, you might consider using rever. Rever is a tool for automating software releases and forms the backbone of the bot's conda-forge PRing capability. Rever is both conda (conda install -c conda-forge rever) and pip (pip install re-ver) installable. Finally, feel free to drop us a line if there are any issues! This PR was generated by https://circleci.com/gh/regro/circle_worker/50633, please use this URL for debugging}

[conda-forge-linter]

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.

[beckermr]

Error is odd

conda.exceptions.ResolvePackageNotFound: 
  - libgfortran=5.dev0

We have this on our channels, but 5.0.0.dev0 as the version.

[beckermr]

@conda-forge-admin restart ci

[beckermr]

more confusing solver issues

Package llvm-openmp conflicts for:
libgfortran5[version='>=11.0.0.dev0'] -> llvm-openmp[version='>=11.0.0.0rc.1|>=8.0.0']
llvm-openmp[version='>=11.0.0.0rc.1']
libgfortran=5 -> libgfortran5 -> llvm-openmp[version='>=11.0.0.0rc.1|>=8.0.0']

Package libgfortran5 conflicts for:
libgfortran5[version='>=11.0.0.dev0']
libgfortran=5 -> libgfortran5
Note that strict channel priority may have removed packages required for satisfiability.

[beckermr]

@conda-forge-admin restart ci

[beckermr]

@conda-forge-admin restart ci

[beckermr]

ok - now we're getting somewhere:

/bin/sh: ./getarch: Bad CPU type in executable

[beckermr]

Looks like they are calling this VORTEX?

https://github.com/xianyi/OpenBLAS/pull/2816/files

I don't follow.

[beckermr]

We'll need to pull the develop version of the code too I think.

[beckermr]

also this

ssytrd_sb2st.F:234:10:

  234 |       use omp_lib
      |          1

[isuruf]

You need the PRs 2813, 2816, 2807 from upstream repo.

[isuruf]

234 | use omp_lib | 1 Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No such file or directory

Should be fixed by https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/pull/23

[beckermr]

Right. I figured this is what was motivating that pr. Thank you!

[beckermr]

@conda-forge-admin restart ci

[beckermr]

@isuruf same error again with the latest compiler

$BUILD_PREFIX/bin/arm64-apple-darwin20.0.0-gfortran -march=armv8.3-a -ftree-vectorize -fPIC -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/openblas-0.3.10 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -frecursive -O2 -fdefault-integer-8 -Wall -frecursive -fno-optimize-sibling-calls -fopenmp -fPIC  -c -o ssb2st_kernels.o ssb2st_kernels.f
2020-09-21T13:03:07.1624940Z ssytrd_sb2st.F:234:10:
2020-09-21T13:03:07.1726570Z 
2020-09-21T13:03:07.1729950Z   234 |       use omp_lib
2020-09-21T13:03:07.1741110Z       |          1
2020-09-21T13:03:07.1742750Z Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No such file or directory

[isuruf]

Needs https://github.com/conda-forge/gfortran_osx-64-feedstock/pull/28

[beckermr]

@conda-forge-admin restart ci

[beckermr]

man this is annoying - compiler is using builds 8 and 9 and still cannot find openmp

$BUILD_PREFIX/bin/arm64-apple-darwin20.0.0-gfortran -march=armv8.3-a -ftree-vectorize -fPIC -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/openblas-0.3.10 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -frecursive -O2 -Wall -frecursive -fno-optimize-sibling-calls -fopenmp -fPIC -c -o ssytrd_sb2st.o ssytrd_sb2st.F
ssytrd_sb2st.F:234:10:

  234 |       use omp_lib
      |          1
Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No such file or directory
compilation terminated.

[beckermr]

@conda-forge-admin restart ci

[beckermr]

@conda-forge-admin restart ci

[beckermr]

@conda-forge-admin restart ci

[beckermr]

Well things are improving

$BUILD_PREFIX/bin/arm64-apple-darwin20.0.0-gfortran -march=armv8.3-a -ftree-vectorize  -fstack-protector -O2 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/openblas-0.3.10 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -frecursive -O2 -fdefault-integer-8 -Wall -frecursive -fno-optimize-sibling-calls -fopenmp  -O2 -fdefault-integer-8 -Wall -frecursive -fno-optimize-sibling-calls -fopenmp  -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs -Wl,-rpath,$PREFIX/lib -L$PREFIX/lib -o dblat1 dblat1.o ../libopenblas64_p-r0.3.10.a -lpthread -lgfortran -lpthread -lgfortran -lomp
ld: library not found for -lquadmath
collect2: error: ld returned 1 exit status

[isuruf]

libquadmath.dylib is not created in the gfortran_impl_osx-64-feedstock. Not sure why

[h-vetinari]

You need the PRs 2813, 2816, 2807 from upstream repo.

Has this been done? With the rerender of the gcc migration I should now have gotten push access, so could fix directly in this PR if desired.

[beckermr]

Has this been done? With the rerender of the gcc migration I should now have gotten push access, so could fix directly in this PR if desired.

No I have not done it yet. More than happy if you have time to work on this.

[h-vetinari]

Since the release of 0.3.11 is just around the corner, I'll probably wait for that. Then we don't need to carry all these patches. But I guess that libquadmath.dylib issue is still open as well?

[beckermr]

But I guess that libquadmath.dylib issue is still open as well?

Yes.