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:
smesh
freecad
And potentially more.

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.

_{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.

[looooo]

disable python2.7! netgen has no support for python2.7

[mhochsteger]

Also disable USE_GUI on Linux (like you have it on Windows already).
GUI with conda always had problems, due to missing private Tcl/Tk headers (which are needed to build Togl).

[looooo]

@mhochsteger gui it is working for the current available linux-builds. I will disable it if it is too difficult to maintain.

this are the current problems:

• osx py3.6: tests:
  Fatal Python error: PyThreadState_Get: no current thread
• osx py3.7: tests:
  error without any message.
• linux gcc7:

../libsrc/include/../visualization/../include/incopengl.hpp:12:14: fatal error: GL/glu.h: No such file or directory
 #    include <GL/glu.h>
              ^~~~~~~~~~

maybe @mingwandroid can give a short statement how to solve cmake-based builds which need the gl-headers which are located in sysroot/include/...

[mingwandroid]

You need to use a cmake toolchain file unfortunately. I am not at home and on a phone so I can't lookup a good reference, please clone AnacondaRecipes/aggregate and have a ripgrep for TOOLCHAIN.

[mingwandroid]

It would be awesome to add a feature to cmake so it queries the compiler as in something like CC -print-sysroot to avoid having to do this.

[looooo]

You need to use a cmake toolchain file unfortunately. I am not at home and on a phone so I can't lookup a good reference, please clone AnacondaRecipes/aggregate and have a ripgrep for TOOLCHAIN.

Thanks, I found this one:
https://github.com/conda-forge/libnetcdf-feedstock/blob/master/recipe/build.sh#L25

It would be awesome to add a feature to cmake so it queries the compiler as in something like CC -print-sysroot to avoid having to do this.

Solving this in a more elegant way would be really nice. But I have to admit that I don't understand the idea.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [19]

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [20]

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

[looooo]

@mhochsteger @JSchoeberl
any ideas?

osx:
2x: Fatal Python error: PyThreadState_Get: no current thread
1x: Segmentation Fault

[mingwandroid]

This happens when an extension module incorrectly links to the Python DSO.

[looooo]

This happens when an extension module incorrectly links to the Python DSO.

@mingwandroid The bindings are done with pybind11. No idea where linking is done incorrectly...

[looooo]

Maybe this is related to the "evil hack" here: https://github.com/NGSolve/netgen/blob/master/libsrc/general/ngpython.hpp#L3

the references PR was merged yesterday. pybind/pybind11#1211

[mhochsteger]

@looooo Thanks for the hint, I updated Netgen and removed the hack. Could you try building the latest version on master?
NGSolve/netgen@63b7719

[looooo]

As you may know, we are using pybind11 from conda-forge and therefor this commit is not yet included. I will try to find a way to use pybind11-master, but for sure this will need a few iterations to get done. Any help is appriciated. Also please have a look at: NGSolve/netgen#21 this is the branch I currently use in this PR. Maybe you can merge.

[looooo]

after rerender linux fails with:

Traceback (most recent call last):
  File "/home/conda/feedstock_root/build_artifacts/netgen_1547455102193/test_tmp/run_test.py", line 2, in <module>
    import netgen
  File "/home/conda/feedstock_root/build_artifacts/netgen_1547455102193/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib/python3.7/site-packages/netgen/__init__.py", line 17, in <module>
    from . import libngpy
ImportError: libGL.so.1: cannot open shared object file: No such file or directory

any ideas?

otool for osx now produces this output:

+ otool -L /Users/distiller/miniconda3/conda-bld/netgen_1547455241930/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.6/site-packages/netgen/libngpy.so
$PREFIX/lib/python3.6/site-packages/netgen/libngpy.so:
	@rpath/libngpy.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libnglib.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libpython3.6m.dylib (compatibility version 3.6.0, current version 3.6.0)
	@rpath/libstl.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libgeom2d.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libcsg.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmesh.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libocc.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)

To me this looks good.

[looooo]

Also looking at the python3.7 build:

@rpath/libpython3.7m.dylib (compatibility version 3.7.0, current version 3.7.0)

seems to be correct. So I don't think the error is because of mixed linked python versions.

[looooo]

ok for linux it seems libGL is not part of the docker image anymore: conda-forge/docker-images@f598f6e
But a system libGL must be installed also for cdt-packages.

[looooo]

@mingwandroid

I found this conversation: https://groups.google.com/a/continuum.io/forum/m/#!topic/anaconda/057P4uNWyCU

So it seems dynamic linking to @rpath/libpython3.6m.dylib should be avoided?

[looooo]

@conda-forge-admin, please rerender

[mingwandroid]

To me this looks good.

It is not good. I mentioned this already here: #14 (comment) . The python DSO should not be getting linked to. Our python interpreters are fully static now on Linux and macOS.

[looooo]

@mingwandroid Sry, I think I misunderstood your comment. I patched the necessary parts with this:
NGSolve/netgen@339f8a1#diff-af3b638bc2a3e6c650974192a53c7291R32

Not sure if this is the correct way. If you know of any better way how to handle this in a cmake-library please let me know.

[mhochsteger]

Do I understand correctly, that libraries providing Python bindings should NOT link at all to libpython? (with Conda on Linux and MacOS)

[mingwandroid]

That is correct.

[mingwandroid]

@looooo your patch looks OK, but you should not be seeing libpython*.dylib from otool -l (that's a better command than otool -L by the way since it doesn't show transitively linked things).