[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache

2016-04-08 Thread Dan Mick
Dan Mick added the comment: So the original author of the code says it's "likely no longer relevant", and it's clearly wrong, but no one has touched this in six years? Even moving the "linker[i] = self.compiler_cxx[i]" inside the if that checks for "env" wo

[issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph

2014-12-02 Thread Dan Mick
Dan Mick added the comment: Belaboring this a bit just in case what I learn helps with the interpreter change: seems like threading.Thread.start() is hanging in its normal wait for start code: (gdb) py-bt #4 Frame 0x25d4de0, for file /usr/lib64/python2.7/threading.py, line 339, in wait

[issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph

2014-12-01 Thread Dan Mick
Dan Mick added the comment: So, finally got to a Fedora21 beta to try this out today; the immediate problem, as identified by Joe Julian, is the shutdown() call in the __del__ method of Rados. Presumably something about object destructors is clashing with starting new threads; the hang

[issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph

2014-11-19 Thread Dan Mick
Dan Mick added the comment: Hi; I'm the original author of the code in the Ceph CLI. The reason it does what it does is that the Python CLI calls into librados (Ceph, through ctypes) to connect to the cluster; that connection can block for various reasons, so it's spawned in a thread; after