You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update PC/pyconfig.h to support disabling auto linking #82909
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2019-11-06.22:41:31.365>labels= ['3.8', 'type-feature', '3.7', '3.9', 'OS-windows']
title='Update PC/pyconfig.h to support disabling auto linking'updated_at=<Date2020-05-12.23:29:17.552>user='https://github.com/jcfr'
When configuring project using build-system generator like CMake, the linking is explicitly handled and does not to be implicitly hard-coded in pyconfig.h
Having the "pythonXY.lib" library hard-coded in pyconfig.h currently requires to explicitly specify a link directory. While possible, this require to increase the complexity of our build-system.
I suggest we introduce a new macro (e.g PY_CONFIG_AUTOLINK_DISABLED)
I'm not totally averse to just removing the link pragmas completely, but since that's got significant compatibility impact, I'm happy with this approach.
Let's shorten the name though. "PY_NO_LINK_LIB" might be better?
jcfr commented on Nov 11, 2019
jcfrmannequin
MannequinAuthor
More actions
PY_NO_LINK_LIB will work well. I will work on a patch later this week.
jcfr commented on May 8, 2020
jcfrmannequin
MannequinAuthor
More actions
Associated pull request has been updated, CLA signed and it is ready for final review and integration.
Thanks for the ping - sorry, I've been largely offline while I'm between internet providers.
The change is fine, but I wonder whether we should document it somewhere? Most likely in the devguide, which is in a separate repo, but perhaps a mention in PCbuild/readme.txt too?
Presumably you looked around for ideas before figuring out the issue - anywhere you might have found it? Just in the source code?
mathstuf commented on May 12, 2020
mathstufmannequin
Mannequin
More actions
Presumably you looked around for ideas before figuring out the issue
Usually when "could not find foo.lib" popping up without any mention of "foo.lib" on the link line points directly to these "autolinking" "features" being the culprit. It's just something I've learned through experience. If there's an FAQ of common problems when building C extensions, it belongs there.
While this functionality sounds nice in principle, it only really works if something also adds the directory to *look* for the library to the link line as well. But if you can get *that* to the link line, you may as well just add the ".lib" to the link line directly and not send the linker on a wild goose chase based on a header. In addition, nothing ties "find python.lib" to the one that actually goes with the header that's telling it to be found either, so you can get the wrong one too (probably not so much an issue for Python now that ABI flags are gone, but it's still a thing).
Due to these behaviors and the lack of a link directory pragma (not that you could write a relocatable one in C preprocessor anyways), I find #pragma comment(lib) to just be a misfeature more than anything.
Activity
jcfr commentedon Nov 6, 2019
When configuring project using build-system generator like CMake, the linking is explicitly handled and does not to be implicitly hard-coded in pyconfig.h
Having the "pythonXY.lib" library hard-coded in pyconfig.h currently requires to explicitly specify a link directory. While possible, this require to increase the complexity of our build-system.
I suggest we introduce a new macro (e.g PY_CONFIG_AUTOLINK_DISABLED)
zooba commentedon Nov 9, 2019
I'm not totally averse to just removing the link pragmas completely, but since that's got significant compatibility impact, I'm happy with this approach.
Let's shorten the name though. "PY_NO_LINK_LIB" might be better?
jcfr commentedon Nov 11, 2019
PY_NO_LINK_LIB will work well. I will work on a patch later this week.
jcfr commentedon May 8, 2020
Associated pull request has been updated, CLA signed and it is ready for final review and integration.
Thanks so much for your time,
zooba commentedon May 12, 2020
Thanks for the ping - sorry, I've been largely offline while I'm between internet providers.
The change is fine, but I wonder whether we should document it somewhere? Most likely in the devguide, which is in a separate repo, but perhaps a mention in PCbuild/readme.txt too?
Presumably you looked around for ideas before figuring out the issue - anywhere you might have found it? Just in the source code?
mathstuf commentedon May 12, 2020
Usually when "could not find foo.lib" popping up without any mention of "foo.lib" on the link line points directly to these "autolinking" "features" being the culprit. It's just something I've learned through experience. If there's an FAQ of common problems when building C extensions, it belongs there.
While this functionality sounds nice in principle, it only really works if something also adds the directory to *look* for the library to the link line as well. But if you can get *that* to the link line, you may as well just add the ".lib" to the link line directly and not send the linker on a wild goose chase based on a header. In addition, nothing ties "find python.lib" to the one that actually goes with the header that's telling it to be found either, so you can get the wrong one too (probably not so much an issue for Python now that ABI flags are gone, but it's still a thing).
Due to these behaviors and the lack of a link directory pragma (not that you could write a relocatable one in C preprocessor anyways), I find
#pragma comment(lib)to just be a misfeature more than anything.gh-82909: Update PC/pyconfig.h to allow disabling pragma based auto-l…
mhsmith commentedon Sep 1, 2025
Fixed by #19740.