Change by Isuru Fernando :
--
keywords: +patch
pull_requests: +30256
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32178
___
Python tracker
<https://bugs.python.org/issu
New submission from Isuru Fernando :
If `cflags` contains something like,
`-I/Users/isuru/handy-archives-env/include`, then the code assumes that there
is a `-arch` flag in it and errors with
ValueError: Don't know machine value for archs=()
--
components: Build
messages: 4
Isuru Fernando added the comment:
Duplicate of https://bugs.python.org/issue45350
--
nosy: +isuruf
___
Python tracker
<https://bugs.python.org/issue44
Change by Isuru Fernando :
--
keywords: +patch
pull_requests: +27071
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28725
___
Python tracker
<https://bugs.python.org/issu
Isuru Fernando added the comment:
Agree that this should be fixed. If you want, I can send a PR.
--
nosy: +isuruf
___
Python tracker
<https://bugs.python.org/issue44
Isuru Fernando added the comment:
Do you have a suggestion for how to make it configurable at compile time?
In POSIX platforms, we can set `--with-tzpath` to make it configurable at
compile time.
--
___
Python tracker
<https://bugs.python.
Change by Isuru Fernando :
--
keywords: +patch
pull_requests: +26896
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28501
___
Python tracker
<https://bugs.python.org/issu
New submission from Isuru Fernando :
It only looks at --sysroot which is Linux specific
--
components: Build
messages: 402338
nosy: FFY00, isuruf
priority: normal
severity: normal
status: open
title: sysroot_paths in setup.py does not consider -isysroot for macOS
versions: Python 3.11
Isuru Fernando added the comment:
Thanks @steve.dower for the info. I've created
https://github.com/python/cpython/pull/28495. Let me know if it needs to have a
separate bpo issue.
--
___
Python tracker
<https://bugs.python.org/is
Change by Isuru Fernando :
--
pull_requests: +26890
pull_request: https://github.com/python/cpython/pull/28495
___
Python tracker
<https://bugs.python.org/issue40
Isuru Fernando added the comment:
> If anyone building Python for Windows shows up needing support for this, we
> can re-visit the issue — I don't believe it's technically infeasible, just
> that the usage patterns of Python on Windows mean that it's not worth doing.
Change by Isuru Fernando :
--
keywords: +patch
nosy: +isuruf
nosy_count: 8.0 -> 9.0
pull_requests: +26810
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28397
___
Python tracker
<https://bugs.python.org/i
Change by Isuru Fernando :
--
nosy: +isuruf
nosy_count: 23.0 -> 24.0
pull_requests: +25069
pull_request: https://github.com/python/cpython/pull/26474
___
Python tracker
<https://bugs.python.org/issu
Isuru Fernando added the comment:
You are right. I think I may have accidentally used the wrong SDK. Explictly
setting `SYSTEM_VERSION_COMPAT=1` is unsupported then?
--
___
Python tracker
<https://bugs.python.org/issue43
New submission from Isuru Fernando :
In macOS Big Sur, if the executable was compiled with
MACOSX_DEPLOYMENT_TARGET=10.15
or below, then SYSTEM_VERSION_COMPAT=1 is the default which means that Big Sur
reports itself as 10.16 which in turn means that __builtin_available(macOS 11.0)
will not be
Change by Isuru Fernando :
--
keywords: +patch
pull_requests: +22407
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23523
___
Python tracker
<https://bugs.python.org/issu
New submission from Isuru Fernando :
Only a few changes are needed and I will send a Pull request.
This was used for providing macos-arm64 builds for conda where we are using
cross compiling exclusively for all macos-arm64 builds
--
components: Build
messages: 381908
nosy: isuruf
Change by Isuru Fernando :
--
pull_requests: +17747
pull_request: https://github.com/python/cpython/pull/18371
___
Python tracker
<https://bugs.python.org/issue33
Isuru Fernando added the comment:
This is an issue even without cross-compilations as there is an environment
variable for the archiver and therefore the archiver and ranlib can be from 2
different toolchains and leads to error. Ran into this issue in python 3.8 on
macOS with an lto build
Isuru Fernando added the comment:
Fixed in https://github.com/python/cpython/pull/12445
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
New submission from Isuru Fernando :
When compiling python 3.6.4 on appveyor using MSVC 2015 following error occurs.
(C:\bld\python_1514037886491\_b_env)
C:\bld\python_1514037886491\work\Python-3.6.4\PCbuild>"C:\Program Files
(x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe&qu
21 matches
Mail list logo
