Daiderd Jordan added the comment:
Either patch looks fine to me, should I close the pull request?
--
___
Python tracker
<https://bugs.python.org/issue34
Daiderd Jordan added the comment:
Even tho it's headers are not /usr/lib/libutil.dylib is available on every
macOS system. Unlike on bsd this doesn't include the relevant symbols for
openpty/forkpty, that's why I used an __APPLE__ condition but including both
also works fine
Daiderd Jordan added the comment:
Oh interesting, so it only used to worked by accident. I should have looked at
the 3.6 log more closely.
--
___
Python tracker
<https://bugs.python.org/issue34
Daiderd Jordan added the comment:
The headers end up in the build environment because of Libsystem which is part
of our base environment. But yes, this is also the case with 3.6 and that
builds just fine so I'm not sure why it's failing now.
These are the logs from our build s
Daiderd Jordan added the comment:
This is a build using the nix package manager, we use all of the opensource
components provided by apple instead of relying on xcode. The libutil.h that's
found in this case is the one from the 10.11.6 sources.
https://opensource.apple.com/source/li
Change by Daiderd Jordan :
--
keywords: +patch
pull_requests: +7664
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34027>
___
___
Py
New submission from Daiderd Jordan :
I can't really figure out why, but the import in posixmodule.c seems
to get skipped since python 3.7. The condition doesn't look entirely correct in
case libutil.h is also available on macOS, however this has not changed since
3.6 and it w
