Rebuild for Python 3.7, GCC 7, R 3.5.1, openBLAS 0.3.2

[regro-cf-autotick-bot]

It is likely this feedstock needs to be rebuilt. Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

This package has the following downstream children: atk autoconf automake bison curl And potentially more.

_{This PR was created by the cf-regro-autotick-bot. The cf-regro-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!}

[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.

[bgruening]

@conda-forge-admin, please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I tried to re-render for you, but it looks like there was nothing to do.

[bgruening]

The error comes from here: https://github.com/perl11/cperl/blob/master/ext/Errno/Errno_pm.PL#L135 I'm wondering if setting locincpth could help.

[bgruening]

@tomkinsc @rvalieris @jerowe @mtw could you please look at this?

[rvalieris]

on the linux-anvil image errno.h is on /usr/include, this newer build uses a different image.

putting the sysroot setting section of build.sh back in solved the error for me.

the trick is to include this part only on the new build. so I guess we could surround it with: if [[ "$CONFIG" == "linux_c_compilergcc" ]]

[bgruening]

@rvalieris thanks for looking into it. Please feel free to add a commit to this repo.

[rvalieris]

sorry, I forgot to mention ! I couldn't push changes to this PR, only recipe maintainers can I guess.

this is the diff of the changes I made: https://gist.github.com/rvalieris/d42b5ce0c4d4197ddca942b0539af6a2

[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.

[bgruening]

@rvalieris I added your patch. Thanks. Let's see what it does. I don't think we can merge it with the build-number hack, but it would be good to know if this solves the problem.

[scopatz]

This is building now!

[bgruening]

Yeah, but we have now this. https://github.com/conda-forge/perl-feedstock/pull/27/files#diff-44a73bcc045c193c3bd45da87994b03bR27

This is probably suboptimal I guess.

[scopatz]

You should be able to check $CF_COMPILER_STACK == "comp7" instead to check if you are building with the new compilers for the moment

[rvalieris]

yea I don't like checking the build number either, but note that after the migration is complete this check won't be necessary anymore.

[scopatz]

That's right, it will have to be removed when the migration is done. There is no good way to avoid that, really.

[bgruening]

@mingwandroid any ideas welcome. But I guess this is just temporary and we remove this when the migration is done. If so is this still a problem for you?

[bgruening]

Feel free to merge if anyone thinks this is a good enough short-term fix.

[mariusvniekerk]

is there a way to easily pass c_compiler to this build script? That way we can just check for toolchain

[bgruening]

Thanks @mariusvniekerk!