--with-valgrind and --enable-shared

Hello, does it have any sense for a linux distribution (arch to be specific) to provide default Python package compiled with valgrind support? I thought this flag was just about silencing false positives generated by valgrind (in other words a workaround for "bugs" of another software) and useful only when developing Python itself or C extensions. The same distribution also compiles by default to a shared library and this has a quite noticeable impact on performance on x64 (surprisingly for me) for CPU bound processing; in a few test cases I measured valgrind+shared Python running at 66% the speed of plain ./configure && make Python on my system. Is this setting reasonable for general users? If they are good defaults, why aren't them the default? Andrea Griffini

On Mon, Mar 23, 2015 at 1:59 PM Andrea Griffini <agriff@tin.it> wrote:
Hello,
does it have any sense for a linux distribution (arch to be specific) to provide default Python package compiled with valgrind support? I thought this flag was just about silencing false positives generated by valgrind (in other words a workaround for "bugs" of another software) and useful only when developing Python itself or C extensions.
It's not really our place to say if it makes sense for Arch to compile with valgrind flags turned on. It really depends on how they use Python in their Linux distribution and what their own goals are.
The same distribution also compiles by default to a shared library and this has a quite noticeable impact on performance on x64 (surprisingly for me) for CPU bound processing; in a few test cases I measured valgrind+shared Python running at 66% the speed of plain ./configure && make Python on my system. Is this setting reasonable for general users?
Once again, it all depends on how Arch uses Python.
If they are good defaults, why aren't them the default?
That's a question for Arch Linux and not us.

On Mon, Mar 23, 2015 at 7:08 PM, Brett Cannon <brett@python.org> wrote:
It's not really our place to say if it makes sense for Arch to compile with valgrind flags turned on. It really depends on how they use Python in their Linux distribution and what their own goals are.
I already asked the package maintainers about this, I just wanted to know if my understanding about what --with-valgrind means is correct or if there are good reason to turn it on (except debugging Python).
If they are good defaults, why aren't them the default?
That's a question for Arch Linux and not us.
I probably didn't explain myself correctly: I was asking why they're not the default values for Python configure script... Andrea

On Mon, 23 Mar 2015 19:16:17 +0100 Andrea Griffini <agriff@tin.it> wrote:
On Mon, Mar 23, 2015 at 7:08 PM, Brett Cannon <brett@python.org> wrote:
It's not really our place to say if it makes sense for Arch to compile with valgrind flags turned on. It really depends on how they use Python in their Linux distribution and what their own goals are.
I already asked the package maintainers about this, I just wanted to know if my understanding about what --with-valgrind means is correct or if there are good reason to turn it on (except debugging Python).
I think your understanding is correct. It's the first time I hear of Python being compiled --with-valgrind in a Linux distribution. As for --enable-shared, it's more of a distro policy and isn't unheard of. The RedHat world (Mageia, etc.) enables it as well. Perhaps it makes updates easier if there are many installed programs embedding the Python interpreter. Regards Antoine.
participants (3)
-
Andrea Griffini
-
Antoine Pitrou
-
Brett Cannon