In regards to the recent conference call [0], which I was unable to attend;
The strong emphasis on Python-core [2] being strictly a build-dep leaves my puzzled. It seems to me that this would not then be applicable to, well, basically any of these software packages as they would still need a runtime dependency on libpython (which was most/all of the packages that [1] wanted to address, like Qt and other non-mpi non-blas software) I'm probably exposing my naivety here, but I don't actually see why it couldn't be even simpler; a Python-core at GCCcore, and a Python at intel/foss that depends on Python-core and only adds numpy and friends. I know Kenneth tested mixing a foss/2017a Python binary with the numpy libraries from intel/2017a (see bottom of [1]), and get an ABI related error. But this is probably just be due to shadowing libpython to start with, e.g. objdump -t libpython2.7.so.1.0 | grep _PyUnicode on foss and intel, I see some ABI differences (which happens to break numpy when mixing toolchains) But if the intel numpy had been built against a GCCcore libpython, it should have linked to the compatible symbols to start with, so this wouldn't have been a problem if we simply always stuck with core libpython (and interpreter). These ABI difference could also affect stuff like Qt as well, so shadowing core libpython with an intel libpython can presumably break things there as well. [0] https://github.com/easybuilders/easybuild/wiki/ Conference-call-notes-20180606 [1] https://github.com/easybuilders/easybuild-easyconfigs/pull/4962 [2] https://github.com/easybuilders/easybuild-easyconfigs/pull/5072 Best regards, Mikael
