[3.6] bpo-35257: Avoid leaking LTO linker flags into distutils (GH-10900) by vstinner · Pull Request #11265 · python/cpython (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation7 Commits3 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

"make profile-opt" no longer replaces CFLAGS_NODIST with CFLAGS. It now adds profile-guided optimization (PGO) flags to CFLAGS_NODIST, existing CFLAGS_NODIST flags are kept.

(cherry picked from commit 640ed52)

When compiling 3rd party C extensions, the linker flags used by the compiler for the interpreter and the stdlib modules, will get leaked into distutils. In order to avoid that, the PY_CORE_LDFLAGS and PY_LDFLAGS_NODIST are introduced to keep those flags separated.

(cherry picked from commit cf10a75)

Why did you combine the PRs from two separate issues into one? It would make things much easier to track if you kept them separate, no?

Why did you combine the PRs from two separate issues into one? It would make things much easier to track if you kept them separate, no?

The first commit isn't important, it's a minor change. But the second commit depends on the first commit. Otherwise, I would get even more conflicts on the backport. So I decided to combine both commits.

Please separate them. I spent a couple of hours earlier trying to decipher and document the tangled mess of the several bpo issues and PRs involved in this sequence over the various branches. Combining these just makes the mess more complicated.

I created PR #11267 for the first change.

@ned-deily: Oh you succeeded to merge it, thanks.

I was trying to create a PR to the second change, but there was a conflict since you already merged this PR :-)

Cool, I'm happy to see this bug fixed in 3.6 as well ;-)