Alexander Grund

Looks like it was a mistake on my side. Tried to reproduce it in a small testcase but failed

I tried this too on a real ppc machine and the minimal reproducer for "issues" I got is `python -c "import numpy as np; np.linalg.test(verbose=3, extra_argv=['-k', 'TestEigvals and test_sq_cases'])"` which...

More minimal reproducer: `python -c "from numpy import array, linalg; linalg.eigvals(array([[1., 2.], [3., 4.]]))"` I suspect a stackoverflow due to GCC misoptimizing OpenBLAS which becomes apparent by FlexiBLAS as FlexiBLAS...

The IBM compiler guys are looking into this. It seems to be indeed a compiler issue since GCC 7. So I'd say this can be closed as there is nothing...

The [GCC developers determined](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799#c21) this a bug in the usage related to the Fortran calling convention: > As described in (https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html), since the first parameter to DGEBAL is of type...

I resolved the conflicts. Please check if that looks ok

I'm only removing the duplicated line which is (erroneously) in the test-CML. The actual correct one is still at https://github.com/boostorg/cobalt/blob/540b6637ef411b45bae7daa4f9f521e7b9338a1e/CMakeLists.txt#L65 Note on "erroneously": This is a requirement of the library...

> I removed the duplicate in test, is it ok now? Synced and updated to see what is left: - Unconditional dependency on Boost.Container (reformatting the other line allows the...

The change at https://github.com/boostorg/cobalt/pull/135/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aL76-R78 was important because otherwise the dependency won't be detected by the dependency scanner in the super project build which requires it on its own line, see...

I see this on a Linux system: ``` $ export PYTHONPATH=$PYTHONPATH:/foo $ spyder ``` And then in the console: ``` In[1]: import os; os.environ['PYTHONPATH'] Out[1]: '/home/alex/pylint_plugins' ``` So to me...