Closed looooo closed 4 years ago
btw.:
conda list
conda info:
I found a working package-combination which also includes a local build of dakota.
_libgcc_mutex 0.1 main
blas 2.12 openblas conda-forge
boost-cpp 1.68.0 h11c811c_1000 conda-forge
bzip2 1.0.8 h516909a_1 conda-forge
ca-certificates 2019.6.16 hecc5488_0 conda-forge
certifi 2019.6.16 py37_1 conda-forge
dakota 6.10 py37h33ec4a3_1 file:///home/lo/Diplomarbeit/dakota-conda-recipes/builds
gsl 2.4 h294904e_1006 conda-forge
icu 58.2 hf484d3e_1000 conda-forge
libblas 3.8.0 12_openblas conda-forge
libcblas 3.8.0 12_openblas conda-forge
libffi 3.2.1 he1b5a44_1006 conda-forge
libgcc-ng 9.1.0 hdf63c60_0
libgfortran-ng 7.3.0 hdf63c60_0
liblapack 3.8.0 12_openblas conda-forge
liblapacke 3.8.0 12_openblas conda-forge
libopenblas 0.3.7 h6e990d7_1 conda-forge
libstdcxx-ng 9.1.0 hdf63c60_0
mpi 1.0 openmpi conda-forge
ncurses 6.1 hf484d3e_1002 conda-forge
nomkl 3.0 0
numpy 1.17.2 py37h95a1406_0 conda-forge
openblas 0.3.7 h6e990d7_1 conda-forge
openmpi 4.0.1 hc99cbb1_2 conda-forge
openssl 1.1.1c h516909a_0 conda-forge
pip 19.2.3 py37_0 conda-forge
python 3.7.3 h33d41f4_1 conda-forge
readline 8.0 hf8c457e_0 conda-forge
setuptools 41.2.0 py37_0 conda-forge
sqlite 3.29.0 hcee41ef_1 conda-forge
tk 8.6.9 hed695b0_1002 conda-forge
wheel 0.33.6 py37_0 conda-forge
xz 5.2.4 h14c3975_1001 conda-forge
zlib 1.2.11 h516909a_1006 conda-forge
while this env doesn't work:
_libgcc_mutex 0.1 main
blas 2.12 openblas conda-forge
boost-cpp 1.70.0 h8e57a91_2 conda-forge
bzip2 1.0.8 h516909a_1 conda-forge
ca-certificates 2019.6.16 hecc5488_0 conda-forge
certifi 2019.6.16 py37_1 conda-forge
dakota 6.10 py37hf2a3b5a_0 conda-forge
gsl 2.5 h294904e_1 conda-forge
icu 64.2 he1b5a44_1 conda-forge
libblas 3.8.0 12_openblas conda-forge
libcblas 3.8.0 12_openblas conda-forge
libffi 3.2.1 he1b5a44_1006 conda-forge
libgcc-ng 9.1.0 hdf63c60_0
libgfortran-ng 7.3.0 hdf63c60_0
liblapack 3.8.0 12_openblas conda-forge
liblapacke 3.8.0 12_openblas conda-forge
libopenblas 0.3.7 h6e990d7_1 conda-forge
libstdcxx-ng 9.1.0 hdf63c60_0
mpi 1.0 openmpi conda-forge
ncurses 6.1 hf484d3e_1002 conda-forge
nomkl 3.0 0
numpy 1.17.2 py37h95a1406_0 conda-forge
openblas 0.3.7 h6e990d7_1 conda-forge
openmpi 4.0.1 hc99cbb1_2 conda-forge
openssl 1.1.1c h516909a_0 conda-forge
pip 19.2.3 py37_0 conda-forge
python 3.7.3 h33d41f4_1 conda-forge
readline 8.0 hf8c457e_0 conda-forge
setuptools 41.2.0 py37_0 conda-forge
sqlite 3.29.0 hcee41ef_1 conda-forge
tk 8.6.9 hed695b0_1002 conda-forge
wheel 0.33.6 py37_0 conda-forge
xz 5.2.4 h14c3975_1001 conda-forge
zlib 1.2.11 h516909a_1006 conda-forge
only building local does't solve the issue. There are only a few different package versions for these two environments:
-boost-cpp 1.70.0 h8e57a91_2 conda-forge
+boost-cpp 1.68.0 h11c811c_1000 conda-forge
-dakota 6.10 py37hf2a3b5a_0 conda-forge
+dakota 6.10 py37h33ec4a3_1 file:///home/lo/Diplomarbeit/dakota-conda-recipes/builds
-gsl 2.5 h294904e_1 conda-forge
+gsl 2.4 h294904e_1006 conda-forge
-icu 64.2 he1b5a44_1 conda-forge
+icu 58.2 hf484d3e_1000 conda-forge
-zlib 1.2.11 h516909a_1006 conda-forge
+zlib 1.2.11 h516909a_1006 conda-forge
@isuruf The build seems to use blas and lapack from netlib, but openblas is specified for the run-dependencies. Can this lead to such incompatibilities?
edit: Forcing netlib libraries [1] for the not working environment solved this issue. So I guess removing the openblas flag in the dakota-recipe will solve this issue.
[1] conda install liblapack=*=*netlib
@isuruf Is there a reason for using netlib instead of openblas by default for the build-env? Creating/updating environments always prefer openblas. So if this issue is not solvable, I think it would be best to switch these lines to openblas: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml#L355L362
Not sure I understand this, but in my eyes this issue is due to incompatibilities between netlib and openblas. Using openblas at build time fixed this issue. But I haven't tried to use netlib packages at run time. https://github.com/conda-forge/dakota-feedstock/pull/8/commits/587c6bf5f817506203cb163fae6deb27b58fcf04
btw.: I encountered another problem with netlib libraries. Somehow calling numpy (version 1.17) resulted in a crash. Using the same version as used for the build solved this issue. But as I am now building dakota with libraries from openblas, no such issue occures with numpy 1.17.
So somehow I have the impression libraries from openblas should be preffered over netlib libraries. I still don't know why netlib is default for the builds. Is there any reason?
I still don't know why netlib is default for the builds. Is there any reason?
Please read the docs I linked above. Is there anything there that's not clear?
Can you give steps to reproduce this?
Can you give steps to reproduce this?
I added a test-file to the dakota-feedstock. This should work with the current build because the build now uses openblas libraries, but I expect it to fail with the netlib libraries. I will report once the error is reproduced on the ci.
@isuruf I was able to reproduce the problem with azure: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=74324&view=logs
The issue is that dmax
symbol is defined in both openblas
and dakota
. When dakota is built with netlib
and openblas is used, openblas' symbol takes precedence, but the two symbols do two different things. When dakota is built with openblas
, somehow this issue goes away.
Thanks @isuruf for digging into this issue. If I have understood correctly this is a problem with dakota not using the right function. I will report this to the dakota-development team and stay with openblas for now.
If I have understood correctly this is a problem with dakota not using the right function.
No, it's not. It's an issue with how we build packages using blas
@isuruf, thanks for the pointer to this ticket. Are you agreeing that we should just do the matrix build of blas_impl as I have done in conda-forge/dakota-feedstock#31?
@looooo did you ever bring this up with the upstream Dakota folks?
Issue:
Testing some function of dakota leads to a segfault which happens in liblapack. This is the backtrace:
I don't think this will be solvable, but maybe someone has a hint whats going wrong here.
The same test worked with an older version of dakota and packages from conda-forge/label/cf201901.