homepage

If you pass LIBS to ./configure (as in "LIBS=-lgcov ./configure"),
distutils ignores this when building extension modules, which breaks
when using certain gcc options which require certain libraries (I'm
thinking of -fprofile-generate). The attached patch remedies this.

issue 5060 address this

The patch attached to issue 5060 seems very tightly focused on a problem
with gcc FDO. This is a more general patch that solves the problem of
distutils ignoring LIBS.

The LIBS contain all module dependent libraries, libpython is linked
with LIBS, modules are linked with libpython.
May be I miss something but I could not found why distutils has to use
LIBS to link a module.

> May be I miss something but I could not found why distutils 
> has to use LIBS to link a module.
It doesn't right now, but depending on the extension you want to build,
you might want to configure it and make sure it is passed to the compiler.
About the patch:
is there a particular reason why you have changed the call to
'set_library' into calls to 'add_library' in build_ext in your patch ?

2009年5月4日 <"Tarek Ziadé <report@bugs.python.org>"@psf.upfronthosting.co.za>:
> About the patch:
>
> is there a particular reason why you have changed the call to
> 'set_library' into calls to 'add_library' in build_ext in your patch ?
Yes. It seems like the proper thing to do is to merge the global LIBS
and the module-specific libraries (via add_library()), rather than
having one override the other (set_library()).

Reclassifying as a feature request for the packaging module. The distutils docs don’t say using LIBS is supported and there aren’t many people asking for it on this bug report.

This wasn't so much a feature request as a request for review. I had already implemented the necessary changes and provided a patch.
We found this change necessary when working on Unladen Swallow.

> This wasn't so much a feature request as a request for review.
From a tracker process viewpoint, any report is a bug, a feature request or a doc bug. A bug can be defined as a discrepancy between the doc and the code. Given that I found no mention of LIBS support in distutils, I tentatively took the conservative way and judged this a new feature. However..
> We found this change necessary when working on Unladen Swallow.
This may change the situation. Why was it necessary? Would other projects need it? Is it a standard in other build tools that’s an obvious oversight in distutils?

I have provided justification in the original patch submission. Without this patch, we were unable to cleanly apply gcc's feedback-directed optimization system to Python. FDO yields significant performance improvements.

I’m afraid performance improvements are not bug fixes, which are the only possible changes in distutils now. This change is however appreciated for packaging.

I have no interest in forward-porting the patch, closing accordingly. At least there will be a record of this patch for anyone interested in getting a free 10% performance boost for their Python 2.x or 3.[012] systems.

The distutils feature freeze doesn’t let us accept this patch, but there is definite value for packaging, so I will port it. Thanks for the original patch!

Collin, I'm sure that you could use LDFLAGS instead LIBS to boost python. If I remember well this require set_executables to be commented in setup.py.

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools