[issue36231] Support builds on macOS without installed system header files
Dmitrii Pasechnik added the comment: Thanks for the review of our PR. I think not all points made there are relevant: * on older systems, where `xcrun --show-sdk-path` is not available, one can assume that /usr/include is there, and simply set the corresponding variable to this value in ./configure * building Python with a non-system compiler is only possible with system headers, and thus either SDK or at least command line tools, available, and all is well. * mid-flight switching to a different SDK/compiler is dodgy, and in particular switching to a different set of headers is asking for trouble. And the gcc toolchain is not much different in this way - e.g. on Gentoo one can do gcc-config to switch from one profile to another, with provably "interesting" results if it is done mid-flight. * the Python 2.7 zlib issue is not a problem with our PR. - Most probably, the desired switch to autotools can only happen gradually, by moving more of setup.py to ./configure, and our PR is a step in such direction. -- ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Dmitrii Pasechnik added the comment: I find it puzzling that a relatively clean and short solution using autotools and the Apple-approved way to get the location of the headers is rejected, and a hacky, longer way that scrapes output of the compiler is being pushed instead. -- ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Dmitrii Pasechnik added the comment: In case,I have opened PR https://github.com/python/cpython/pull/12825 to provide our solution to this issue. -- ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Change by Dmitrii Pasechnik : -- pull_requests: +12750 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36106] resolve sinpi() name clash with libm
Dmitrii Pasechnik added the comment: Can this also be backported to 3.5. and 3.6, as requested by FreeBSD maintainers? -- ___ Python tracker <https://bugs.python.org/issue36106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36432] Running python test suite fails on macOS 10.14.4 with resource.RLIMIT_STACK error
Change by Dmitrii Pasechnik : -- nosy: +dimpase ___ Python tracker <https://bugs.python.org/issue36432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36344] install_certificates.command too complicated, copy from pip's dir instead
Dmitrii Pasechnik added the comment: The script install_certificates.command depends upon pip, it calls pip to install certifi. Thus it's no less "optional" than pip. And pip is only functional, and it able to do the installation in question, due to it including the certificate in question. The role of this script is fishy from security point of view, too. Why not simply putting the certificate right where it belongs to, i.e. not just simplify install_certificates.command, but simply get rid of it? -- ___ Python tracker <https://bugs.python.org/issue36344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36344] install_certificates.command too complicated, copy from pip's dir instead
New submission from Dmitrii Pasechnik : Currently (e.g. on the released Python 2.7.16) Mac/BuildScript/resources/install_certificates.command does install certifi module from the net and symlinks its cacert.pem to provide openssl with a working certificate. The same task may be accomplished much easier, by symlinking pip's cacert.pem, as follows (just shell commands, for the purposes of demonstration) cd local/openssl rm -f local/openssl/cert.pem ln -s ../lib/python2.7/site-packages/pip/_vendor/certifi/cacert.pem cert.pem This works as pip's cacert.pem contains the same certificate as the one provided by unvendored certifi (as can be seen by looking at it using "openssl x509 -in ..." on it). I'd be happy to provide a PR if this is acceptable. -- components: macOS messages: 338211 nosy: dimpase, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: install_certificates.command too complicated, copy from pip's dir instead type: enhancement versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue36344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Dmitrii Pasechnik added the comment: I won't mind to provide a PR for this. but it is not clear what the goal should be. Is it to build a working OSX Python with as few external to Xcode deps (it seems that only lzma is needed) as possible? -- ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks
Dmitrii Pasechnik added the comment: On https://bugs.python.org/issue36231 I propose a way to build without creating any symlinks. -- nosy: +dimpase ___ Python tracker <https://bugs.python.org/issue34956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Dmitrii Pasechnik added the comment: Needless to say, subprocess is most certainly an overkill, something less involved would do the job, without the need for all the module dependencies of subprocess. -- ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
New submission from Dmitrii Pasechnik :
Neither Xcode nor its command-line tools on macOS 10.14 Mojave come with header
files installed in /usr/ and other "normal" directories.
This is not documented in https://devguide.python.org/setup/#macos-and-os-x
While an extra step to handle this, i.e. to install the headers, is available
(see a discussion on https://bugs.python.org/issue34956), Apple stated that
this workaround will disappear.
It is thus highly desirable to provide a way to deal with headers located not
at /usr/include, but at `xcrun --show-sdk-path`/usr/include.
A small change in setup.py along the lines of the following:
--- a/setup.py
+++ b/setup.py
@@ -134,7 +134,8 @@ def macosx_sdk_root():
cflags = sysconfig.get_config_var('CFLAGS')
m = re.search(r'-isysroot\s+(\S+)', cflags)
if m is None:
-sysroot = '/'
+import subprocess
+sysroot = subprocess.check_output(["xcrun",
"--show-sdk-path"]).decode("utf-8").strip('\n')
else:
sysroot = m.group(1)
return sysroot
@@ -146,6 +147,7 @@ def is_macosx_sdk_path(path):
"""
return ( (path.startswith('/usr/') and not path.startswith('/usr/local'))
or path.startswith('/System/')
+or path.startswith('/Applications/')
or path.startswith('/Library/') )
with the necessary changes to enable various modules (see attachment for a
complete POC diff against the current master), the result builds and passes all
the (enabled) tests on an OSX 10.13 system with empty /usr/include and
/usr/local/include containing only LZMA headers.
Needless to say, a proper patch would not modify Modules/Setup, it'd adjust
configure.ac etc.
--
components: macOS
files: noincludedirs_OSX.patch
keywords: patch
messages: 337461
nosy: dimpase, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: no "proper" header files on macOS 10.14 Mojave
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file48192/noincludedirs_OSX.patch
___
Python tracker
<https://bugs.python.org/issue36231>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36106] resolve sinpi() name clash with libm
Change by Dmitrii Pasechnik : -- pull_requests: +12076 ___ Python tracker <https://bugs.python.org/issue36106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36106] resolve sinpi() name clash with libm
Dmitrii Pasechnik added the comment: e.g. if I rename `m_lgamma` to `lgamma` I get ``` mathmodule.c:389:1: error: static declaration of ‘lgamma’ follows non-static declaration lgamma(double x) ``` -- ___ Python tracker <https://bugs.python.org/issue36106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36106] resolve sinpi() name clash with libm
Dmitrii Pasechnik added the comment: This has a potential header conflict. For the same reason functions like lgamma, etc. are prefixed with `m_` in Modules/mathmodule.c -- ___ Python tracker <https://bugs.python.org/issue36106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36106] resolve sinpi() name clash with libm
New submission from Dmitrii Pasechnik : The standard math library (libm) may follow IEEE-754 recommendation to include an implementation of sinPi(), i.e. sinPi(x):=sin(pi*x). And this triggers a name clash, found by FreeBSD developer Steve Kargl, who worken on putting sinpi into libm used on FreeBSD (it has to be named "sinpi", not "sinPi", cf. e.g. https://en.cppreference.com/w/c/experimental/fpext4) -- components: Extension Modules messages: 336519 nosy: dimpase priority: normal pull_requests: 12059 severity: normal status: open title: resolve sinpi() name clash with libm type: compile error versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
