search

conda-forge / vtk-feedstock

A conda-smithy repository for vtk.
BSD 3-Clause "New" or "Revised" License
13 stars 64 forks source link

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

Closed regro-cf-autotick-bot closed 5 years ago

regro-cf-autotick-bot commented 5 years ago

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: mayavi 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 commented 5 years ago

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.

isuruf commented 5 years ago

This is now 18 builds with 1 hour each.

grlee77 commented 5 years ago

mesalib rebuilds are still pending: conda-forge/mesalib-feedstock#18 jsoncpp will need to be bumped to 1.8.4

jakirkham commented 5 years ago

jsoncpp will need to be bumped to 1.8.4

Could you please send a PR to conda-forge-pinning with that change?

grlee77 commented 5 years ago

Could you please send a PR to conda-forge-pinning with that change?

sure. see conda-forge/conda-forge-pinning-feedstock#152

looooo commented 5 years ago

is it possible to reduce the build-matrix?

jakirkham commented 5 years ago

After the compiler migration, we should be able to drop the legacy compilers. We could try to drop them as part of this PR. That might work.

looooo commented 5 years ago

@jakirkham

Blocked by upstream PR ( conda-forge/mesalib-feedstock#18 ).

What about using cdt-packages?

https://github.com/AnacondaRecipes/vtk-feedstock/blob/master/recipe/meta.yaml#L36L53

CJ-Wright commented 5 years ago

cycle for ci

grlee77 commented 5 years ago

It would be great to get this one in for the migration.

The Python windows build from two days ago failed for 3.7 with a message about not being able to convert const char* to char *: https://ci.appveyor.com/project/conda-forge/vtk-feedstock/builds/21480875/job/uvhg52ilgq6ulaxb#L1102

Fixing that may require bumping VTK to 8.1.2? (PyPI has py37 wheels for 8.1.2 as of Nov 28th): https://gitlab.kitware.com/vtk/vtk/issues/17407#note_466287

It doesn't looked like closing and reopening triggered new linux builds. I assume that was to test with recently merged mesa? Perhaps we should ask the bot to rerender (at night or on the weekend when the CI is less busy).

grlee77 commented 5 years ago

you may need to manually cancel the CircleCI builds from the outdated 0c50a5d commit. It looks like they are currently still in the queue (not sure if outdated commits get automatically skipped or not?) : https://circleci.com/gh/conda-forge/vtk-feedstock/tree/pull%2F72

edit: nevermind, it looks like the outdated jobs are automatically getting cancelled.

grlee77 commented 5 years ago

After the compiler migration, we should be able to drop the legacy compilers. We could try to drop them as part of this PR. That might work.

What is the mechanism to drop toolchain, keeping only the new compiler builds? Now that the migration is scheduled for next Tuesday, it doesn't seem like there is much point in running the toolchain builds.

grlee77 commented 5 years ago 
  File "/opt/conda/lib/python3.6/site-packages/conda/resolve.py", line 172, in verify_specs
    raise ResolvePackageNotFound(bad_deps)
conda.exceptions.ResolvePackageNotFound: 
  - jsoncpp=1.8.1

This recipe must be rerendered to get the latest pinnings (only 1.8.4 was built for the gcc7 label)

grlee77 commented 5 years ago

Also, I don't remember if there was a strong requirement for the HDF 1.10.1 pin or if it is possible to remove that. The current version in conda-forge-pinning is 1.10.4. It may be worth removing the pin and see how it goes.

edit: It looks like VTK currently uses 1.10.3 here, so probably 1.10.1 is just outdated.

marcelotrevisani commented 5 years ago

@conda-forge-admin , please rerender

conda-forge-linter commented 5 years ago

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.

conda-forge-linter commented 5 years ago

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.

marcelotrevisani commented 5 years ago

That is strange

/Users/distiller/miniconda3/conda-bld/vtk_1547167111297/test_tmp/conda_test_runner.sh: line 2: 28303 Segmentation fault: 11  "/Users/distiller/miniconda3/conda-bld/vtk_1547167111297
grlee77 commented 5 years ago

Getting closer, but there are still a number of problems. Here is what I found in some of the logs:

linux gcc7 cases fail with or without mesa:

[1466/7870] Building CXX object Rendering/OpenGL2/CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o
FAILED: Rendering/OpenGL2/CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o 
$BUILD_PREFIX/bin/x86_64-conda_cos6-linux-gnu-c++  -DVTK_IN_VTK -DvtkRenderingOpenGL2_EXPORTS -I$PREFIX/include -IRendering/OpenGL2 -I../Rendering/OpenGL2 -ICommon/Core -I../Common/Core -IUtilities/KWIML -I../Utilities/KWIML -IUtilities/KWSys -I../Utilities/KWSys -ICommon/DataModel -I../Common/DataModel -ICommon/Math -I../Common/Math -ICommon/Misc -I../Common/Misc -ICommon/System -I../Common/System -ICommon/Transforms -I../Common/Transforms -ICommon/ExecutionModel -I../Common/ExecutionModel -IRendering/Core -I../Rendering/Core -ICommon/Color -I../Common/Color -ICommon/ComputationalGeometry -I../Common/ComputationalGeometry -IFilters/Core -I../Filters/Core -IFilters/General -I../Filters/General -IFilters/Geometry -I../Filters/Geometry -IFilters/Sources -I../Filters/Sources -IUtilities/EncodeString -I../Utilities/EncodeString -IThirdParty/glew -I../ThirdParty/glew -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I$PREFIX/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix  -O3 -DNDEBUG -fPIC -fvisibility=hidden   -std=c++11 -MD -MT Rendering/OpenGL2/CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o -MF Rendering/OpenGL2/CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o.d -o Rendering/OpenGL2/CMakeFiles/vtkRenderingOpenGL2.dir/vtkXOpenGLRenderWindow.cxx.o -c ../Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx
../Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:34:10: fatal error: GL/glx.h: No such file or directory
 #include "GL/glx.h"
          ^~~~~~~~~~
compilation terminated.

osx_cxx_compilerclangxxpython3.6 builds, but fails during testing:

===== testing package: vtk-8.1.2-py36h8c0c073_1200 =====
running run_test.py
===== vtk-8.1.2-py36h8c0c073_1200 OK =====
import: 'vtk'
Fatal Python error: PyThreadState_Get: no current thread

and for 3.7 on OSX with either compiler there is a segfault:

running run_test.py
===== vtk-8.1.2-py37h8c0c073_1200 OK =====
import: 'vtk'
/Users/distiller/miniconda3/conda-bld/vtk_1547176409385/test_tmp/conda_test_runner.sh: line 2: 24017 Segmentation fault: 11  "/Users/distiller/miniconda3/conda-bld/vtk_1547176409385/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/python" -s "/Users/distiller/miniconda3/conda-bld/vtk_1547176409385/test_tmp/run_test.py"
Tests failed for vtk-8.1.2-py37h8c0c073_1200.tar.bz2 - moving package to /Users/distiller/miniconda3/conda-bld/broken
WARNING:conda_build.build:Tests failed for vtk-8.1.2-py37h8c0c073_1200.tar.bz2 - moving package to /Users/distiller/miniconda3/conda-bld/broken
TESTS FAILED: vtk-8.1.2-py37h8c0c073_1200.tar.bz2
Exited with code 1
looooo commented 5 years ago

I am stuck with porting the netgen-feedstock because of similar problems on osx. So I am very interested in the solution (if there is one).

For netgen we solved the problem with linking to Gl/... by adding cdt-packages. Not sure if this is the right solution.

looooo commented 5 years ago

for failing osx with either Segmentation fault or PyThreadState_Get: no current thread remove the dynamic linking to python. https://groups.google.com/a/continuum.io/forum/m/#!topic/anaconda/057P4uNWyCU Maybe someone can explain what is going on here...

looooo commented 5 years ago

Maybe this causes the linking problem for osx?

diff --git a/VTK-8.1.2/CMake/vtkPythonWrapping.cmake b/VTK-8.1.2/CMake/vtkPythonWrapping.cmake
index 01f74bce..fa5043f6 100644
--- a/VTK-8.1.2/CMake/vtkPythonWrapping.cmake
+++ b/VTK-8.1.2/CMake/vtkPythonWrapping.cmake
@@ -122,8 +122,6 @@ function(vtk_add_python_wrapping_library module srcs)
     PROPERTY INCLUDE_DIRECTORIES ${_python_include_dirs})
   target_link_libraries(${module}PythonD LINK_PUBLIC
     vtkWrappingPythonCore ${extra_links})
-  vtk_target_link_libraries_with_dynamic_lookup(
-    ${module}PythonD LINK_PUBLIC ${VTK_PYTHON_LIBRARIES})

   if (MSVC)
     set_target_properties(${module}PythonD
looooo commented 5 years ago

The anaconda-recipe uses a patch which seems to be related to libpython linking: https://github.com/AnacondaRecipes/vtk-feedstock/blob/master/recipe/0001-Link-libpython-optionally-make-vtkPython-dep-compile.patch

looooo commented 5 years ago

The patches apply also to vtk 8.1.2. So maybe someone can add them. Should solve the osx-builds.

Any ideas why linux + new-compilers fail?

looooo commented 5 years ago 
FAILED: bin/vtkProbeOpenGLVersion 
: && $BUILD_PREFIX/bin/x86_64-conda_cos6-linux-gnu-c++  -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I$PREFIX/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix  -O3 -DNDEBUG  -Wl,-lc  -Wl,-lc -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,-rpath,$PREFIX/lib -L$PREFIX/lib     -rdynamic Rendering/OpenGL2/CMakeFiles/vtkProbeOpenGLVersion.dir/vtkProbeOpenGLVersion.cxx.o  -o bin/vtkProbeOpenGLVersion  -Wl,-rpath,$SRC_DIR/build/lib lib/libvtkRenderingOpenGL2-8.1.so.1 lib/libvtkRenderingCore-8.1.so.1 lib/libvtkFiltersCore-8.1.so.1 $PREFIX/lib/libSM.so $PREFIX/lib/libICE.so $PREFIX/lib/libX11.so /usr/lib64/libXext.so $PREFIX/lib/libXt.so lib/libvtkCommonExecutionModel-8.1.so.1 lib/libvtkCommonDataModel-8.1.so.1 lib/libvtkCommonTransforms-8.1.so.1 lib/libvtkCommonMisc-8.1.so.1 lib/libvtkCommonMath-8.1.so.1 lib/libvtkCommonCore-8.1.so.1 -ltbb -Wl,-rpath-link,$SRC_DIR/build/lib && :
$BUILD_PREFIX/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: Rendering/OpenGL2/CMakeFiles/vtkProbeOpenGLVersion.dir/vtkProbeOpenGLVersion.cxx.o: in function `vtkRenderingOpenGL2_ModuleInit::~vtkRenderingOpenGL2_ModuleInit()':
vtkProbeOpenGLVersion.cxx:(.text._ZN30vtkRenderingOpenGL2_ModuleInitD2Ev[_ZN30vtkRenderingOpenGL2_ModuleInitD5Ev]+0x2): undefined reference to `vtkRenderingOpenGL2_AutoInit_Destruct()'

@mingwandroid I see linking to "/usr/lib64/libXext.so" which I guess should not happen, as there is no cdt specified for this library. But this is not the issue why linux fails.

mariusvniekerk commented 5 years ago

@conda-forge-admin please rerender

mariusvniekerk commented 5 years ago

@conda-forge-admin please rerender

grlee77 commented 5 years ago

This was completed except for the OSMESA case in #73