Repository navigation
Conversation
|
All commit authors signed the Contributor License Agreement. |
Documentation build overview
|
There was a problem hiding this comment.
Docs-only changes don't need changelog entries, so please remove this.
(This blurb section is badly named, sorry! It's meant for changes to the build script and such.)
| On macOS, a *name* that is not an absolute path may only be searched | ||
| for in system locations such as :file:`/usr/lib`. Libraries and | ||
| frameworks in folders like :file:`/usr/local/lib`, :file:`~/lib` or | ||
| :file:`~/Library/Frameworks` are then not found, so pass the full path. | ||
| Setting :envvar:`!DYLD_LIBRARY_PATH` or :envvar:`!DYLD_FRAMEWORK_PATH` | ||
| before starting Python adds search locations, but macOS ignores these | ||
| variables for some executables. |
There was a problem hiding this comment.
I agree with Petr that we should be more explicit about the fact that ctypes.CDLL calls dlopen, and thus inherits any quirks from the system-level function. Once we've done that, I'm not sure it's necessary to document all the individual quirks of what a given OS does.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
On macOS,
CDLLwith a relative name may only search system locations such as/usr/lib, so libraries in/usr/local/lib,~/libor~/Library/Frameworksare not found. This adds a short note underCDLLsaying to pass the full path, and thatDYLD_LIBRARY_PATH/DYLD_FRAMEWORK_PATHhelp only for some executables.The test results behind each sentence are in my comment on the issue: #88130 (comment)
I left out
find_library(). It found the library in every test, but the docs call it soft deprecated. Happy to add a mention if you think it belongs here.