Open h-vetinari opened 2 years ago
Now cvxpy on aarch is failing broadly due to this. I'm disabling the aarch tests there. Comments or inputs welcome.
Actually, I had already raised an issue for this at the time... There's also a bit of discussion in https://github.com/conda-forge/cvxopt-feedstock/issues/55, including a handy reference from Isuru.
I just ran into some very strange errors in https://github.com/conda-forge/staged-recipes/pull/16888
After some googling, it seems that this is a problem plaguing many users (especially with pytorch/tensorflow). I'm admittedly out of my depths with this, but the following explanation seemed pretty good:
This has some unfortunate side effects like how changing the import order between libraries will make the error appear / go away. Such kinds of accidents lead to the proliferation of unfortunate (because: randomly working or not) advice of e.g. to uninstall a conda-package and reinstall it from pip.
There's apparently a glibc fix for this since 2015 / glibc 2.22. Unfortunately, not even moving to CentOS 7 (#1436) would help with that, so - coming back to the original quote above - I wanted to ask:
is it possible for conda-forge to consistently enforce dynamic TLS in libgomp?
Not sure if that's possible or even a good idea, but I wanted to raise this issue so that conda-forge users don't run into such cryptic problems - if there's a way to avoid it.