Chi Hsuan Yen <yan12...@gmail.com> added the comment:
I can confirm a rebuild fixes _gdbm for Python 3.6.4.
This is also a bug in gdbm - it should bump soname (gdbm.so.4 => gdbm.so.5) for
such an ABI incompatibility. I've sent a report to gdbm d
Change by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32484>
___
_
Chi Hsuan Yen <yan12...@gmail.com> added the comment:
Most likely the same issue as issue31652. Passing --without-ensurepip to
./configure is a workaround.
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://
Chi Hsuan Yen <yan12...@gmail.com> added the comment:
As https://github.com/python/cpython/pull/98 is merged, this issue is fixed.
Thanks haypo for the review!
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Change by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26467>
___
_
Chi Hsuan Yen <yan12...@gmail.com> added the comment:
This is a pip bug https://github.com/pypa/pip/issues/3063
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Chi Hsuan Yen <yan12...@gmail.com> added the comment:
Might be caused by this bug: https://github.com/pypa/pip/issues/3532
pip uses lockfile, and lockfile uses hard links, which are prohibited on newer
Android versions unless you're root. A workaround is configuring python with
|./con
Change by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31769>
___
_
Chi Hsuan Yen <yan12...@gmail.com> added the comment:
> even if cflags/ldflags are ok
Might be this. setup.py doesn't use -I flags in $CFLAGS. It looks into
$CPPFLAGS only.
--
___
Python tracker <rep...@bugs.python.org>
<https
Chi Hsuan Yen <yan12...@gmail.com> added the comment:
IIRC bugs of bugs.python.org should go to
http://psf.upfronthosting.co.za/roundup/meta/
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Chi Hsuan Yen added the comment:
Thanks to Serhiy Storchaka's work in issue 30152, this patch can be simplified.
I've rebased my branch and updated the pull request.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10496>
___
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29804>
___
_
Chi Hsuan Yen added the comment:
I guess you were asking whether the newly compiled Python binary is able to
build extension modules or not? I rebased PR 139 against the latest git master
and seems it's fine. Running `make distclean`, `./configure` and then `make`
builds all modules
Chi Hsuan Yen added the comment:
Update: my pull request at https://github.com/libffi/libffi/pull/288 is merged.
Future libffi releases don't need pkg-config anymore. However, I guess the
system copy won't be updated in near future.
--
___
Python
Chi Hsuan Yen added the comment:
That's a great feature! Here's a question: what should be CPython's behavior
when PYTHONHISTORY is explicitly set to empty? Currently there's an error:
$ PYTHONHISTORY= ./python
Python 3.7.0a0 (master:f6595983e08fe20cf06a2535d74d912c6dbb044f, Mar 12 2017,
19
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29779>
___
_
Chi Hsuan Yen added the comment:
I've just tried with the latest git-master. With NDK r13b and my build scripts,
[1] test_curses passed.
shell@ASUS_Z00E_2:/data/local/tmp $ python3.7m -m test test_curses -u curses
Run tests sequentially
0:00:00 [1/1] test_curses
1 test OK.
Total duration
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29708>
___
_
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28747>
___
_
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20916>
___
_
Chi Hsuan Yen added the comment:
> Is tmpfile() available on Android?
Yes. Just tried it with Android NDK r13 with clang and API 21 (Android 5.0).
Here's the source code test.c:
#include
int main()
{
FILE *fp = NULL;
char c = '\0';
fp = tmpfile();
fprintf(fp, &qu
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7438>
___
_
Chi Hsuan Yen added the comment:
Thanks for the response. Sorry if my previous work on Android brings confusion.
To prevent possible wasting of time in the future, I'd like to confirm myself
for some conclusions: CPython's support for Android targets only stable
releases of the official NDK
Chi Hsuan Yen added the comment:
I see your points. Indeed in many times I didn't think carefully before leaving
a comment, and not even noticing that my comments can be offensive afterwards.
I apologize for all those cases and I'll be more careful when interacting with
others in the future
Chi Hsuan Yen added the comment:
> Any reason why you do omit mentioning these important facts in the issue ?
Both in the title of this issue and that PR, I mention "NDK r14 beta 2". I'm
not sure what you're referring to. On IRC, irker states the title first and
then the comme
Chi Hsuan Yen added the comment:
Well, I have to commit changes to configure and pyconfig.h, otherwise Travis
tests fail. Maybe .travis.yml should call autoreconf first.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Chi Hsuan Yen added the comment:
I've improved the patch and submitted it as PR 159. Now on Android:
1. _locale is built
2. _locale has several symbols, including CODESET
3. _locale doesn't have nl_langinfo()
Basically _locale maps what langinfo.h does. On Android langinfo.h has several
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
pull_requests: +124
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29436>
___
_
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29591>
___
_
Chi Hsuan Yen added the comment:
Here are test results for PR 53:
shell@ASUS_Z00E_2:/data/local/tmp $ python3.7m -m test -u curses test_curses
Run tests sequentially
0:00:00 [1/1] test_curses
1 test OK.
Total duration: 1 sec
Tests result: SUCCESS
abcshell@ASUS_Z00E_2:/data/local/tmp $
I know
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
Removed file: http://bugs.python.org/file46511/setup-argparse.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Chi Hsuan Yen added the comment:
Now I have a working patch at PR 139, and dropping optparse is still the way to
go, so I reopen it.
I'm not familiar with CPython conventions. Sorry if reopening an issue is
impolite.
--
resolution: not a bug ->
status: closed ->
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
pull_requests: +99
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29442>
___
_
Chi Hsuan Yen added the comment:
As PR 119 is closed, I'll continue this in issue29442
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Chi Hsuan Yen added the comment:
Aha the fix is simple => issue29567
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29442>
___
___
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
pull_requests: +78
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29567>
___
_
New submission from Chi Hsuan Yen:
When proposing a fix for issue29442, I got another issue - argparse can't be
used in setup.py for native (non-cross) builds because argparse imports gettext
and gettext imports struct. I'll propose a fix for that.
--
components: Build
messages
Chi Hsuan Yen added the comment:
Some CJK character are marked as "ambiguous width". Seems in this patch
ambiguous characters are assumed as narrow. Maybe it's better to document it?
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bu
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
title: Remove an unused #include from bltinmodule.c -> Remove unused #include
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Chi Hsuan Yen added the comment:
Hmmm, seems there are more redundant #include ; let me check one by
one
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
pull_requests: +58
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29556>
___
_
New submission from Chi Hsuan Yen:
This #include is added in b744ba1d14c5487576c95d0311e357b707600b47 (issue8610)
and later the use of CODESET is removed in
d64e8a75e5138d5e5970f0c70995ae5cc377c421 (issue9642).
Found this in investigating issue29436
Add haypo as both commit is written by you
Chi Hsuan Yen added the comment:
You're right. argparse has indirect dependency on dynamic modules so it can't
be used in setup.py. Cross builds use prebuilt Python binaries so there's no
problem. Sorry for those noises.
I still think it's a dirty hack as it limits scalability and brings lots
Chi Hsuan Yen added the comment:
>From CPython's developer guide [1]:
"Issues about the tracker should be reported to the meta tracker."
> which doesn't support HTTPS at all
I don't know where I should go for issues about the meta tracker. Maybe a
meta-meta tracker? :D
[1
Chi Hsuan Yen added the comment:
I have used my old patch several days on Android, and it seems quite fine.
Anyway that's not important anymore.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
I've found a simpler patch set for supporting Android builds, so I don't need
this patch anymore. If you don't think it's necessary, just close it.
> usage of os.system() in some places
I'm indeed sick with them
Chi Hsuan Yen added the comment:
That's super strange. crypt() is used in _crypt module only, and this modules
is not used elsewhere in Python. A few more tests may help diagnostics
1. What's the result of ```./python -E```?
2. Does `import crypt` run fine in ./python?
3. Are there pre
Chi Hsuan Yen added the comment:
Duplicate of http://psf.upfronthosting.co.za/roundup/meta/issue463
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
My patch at https://hg.python.org/cpython/rev/ca2f024ce7cb may help. It points
out missing symbols earlier.
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27640>
___
_
Chi Hsuan Yen added the comment:
Just tried boot-flag.patch with
https://github.com/python/cpython/commit/16e07881bd3867d471dd0a25c5117672b65c90ee.
Doesn't work out-of-box:
#./Programs/_freeze_importlib \
./Lib/importlib/_bootstrap.py Python/importlib.h
/bin/sh: line 1: ./Lib/importlib
Chi Hsuan Yen added the comment:
Actually my device is 6.0. Seems there's nothing interesting between API 23 and
24 on android-changes-for-ndk-developers.md :)
Anyway, _decimal should not depend on the whether the python binary references
to libm.so or not. Instead, _decimal should explicitly
Chi Hsuan Yen added the comment:
> If yes, can we close the issue?
Yes and thanks! As a side note, on Android it prevents broken
grp.cpython-37m.so, too.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python
Chi Hsuan Yen added the comment:
Sorry, -lgdbm should come after -lgdbm_compat, or symbols in libgdbm.a are
still not resolved. I don't know why - linking is a magic :(
--
Added file: http://bugs.python.org/file46517/gdbm.patch
___
Python tracker
New submission from Chi Hsuan Yen:
The change is clear and self-explained. See the patch.
Motivations:
1. The hack "To prevent optparse from raising an exception..." works for single
letter flags (-I, -L, etc.) only. I plan to add --sysroot related codes for
Android builds and I
Chi Hsuan Yen added the comment:
Add the developer who wrote this line (issue15044)
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Chi Hsuan Yen:
In setup.py, _dbm links to gdbm_compat only. If gdbm is built as dynamic
libraries, libgdbm_compat.so has a NEEDED flag for libgdbm.so, so both symbols
in libgdbm and libgdbm_compat can be used. However, as static libraries does
not provide such a flag
New submission from Chi Hsuan Yen:
Just like issue21668, _decimal requires -lm on Android. This wasn't fixed
because _decimal didn't build before issue26846 lands. More specificially,
log10 is called
https://hg.python.org/cpython/file/tip/Modules/_decimal/libmpdec/mpdecimal.c#l7862
Added
Chi Hsuan Yen added the comment:
Here's a copy of $ANDROID_NDK/sysroot/usr/include/langinfo.h. (/sysroot/ stores
unified headers [1]) To use those headers correctly, packagers have to add
-D__ANDROID_API__=XY to CPPFLAGS. On the other hand, __ANDROID_API_FUTURE__ is
defined in $ANDROID_NDK
New submission from Chi Hsuan Yen:
Since Android NDK r14 beta 2, unified headers provide langinfo.h but there's no
nl_langinfo() in it, causing linking failures:
libpython3.7m.a(pylifecycle.o): In function `get_locale_encoding':
/home/yen/Projects/python3-android/src/cpython/Python
Chi Hsuan Yen added the comment:
Hello, any updates here? I hope this merged soon so that potential issues on
obscure platforms can be fixed as soon as possible.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
Could you upload a copy of config.log?
Also added developers that play in random.h games
--
components: +Build
nosy: +Chi Hsuan Yen, benjamin.peterson, haypo
___
Python tracker <rep...@bugs.python.org>
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29308>
___
_
Chi Hsuan Yen added the comment:
Thanks for the comment and sorry for the mistake. Here's another updated patch.
In PEP7:
> Use 4-space indents and no tabs at all.
Does that apply to configuration files, too?
--
Added file:
http://bugs.python.org/file46302/prohibit-implicit-funct
Chi Hsuan Yen added the comment:
Since Python 3.6, building ctypes with bundled libffi is deprecated. Please
build libffi separately and configure CPython with --with-system-ffi.
This issue can be closed as third-party.
--
nosy: +Chi Hsuan Yen
Chi Hsuan Yen added the comment:
Here's a new patch using fake library names.
And thanks for those related issues about asdl_c.py!
--
Added file: http://bugs.python.org/file46273/issue29082_3.patch
___
Python tracker <rep...@bugs.python.org>
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29240>
___
_
Chi Hsuan Yen added the comment:
I guess replace mkstemp (C function) with tempfile.mkstemp (Python function)
can solve the problem.
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
> Note that the system libffi must also be compiled with these same flags
Just tried. With my packaging scripts, CPython on ARM is compiled with
-mfloat-abi=softfp -mfpu=vfpv3-d16 while libffi not. test_ctypes pass as usual.
Maybe ctypes test su
Chi Hsuan Yen added the comment:
https://github.com/pywin32/pypiwin32/pull/2
Anyway this is not a Python issue but pywin32's.
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
Here's a how-to for reproducing this bug on Sierra:
1. Install Xcode 7.3.1 (All 7.x should be fine)
2. ./configure
--enable-universalsdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
3. make
On Benjamin's
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
Added file: http://bugs.python.org/file46109/issue29057.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29057>
___
_
Chi Hsuan Yen added the comment:
Oops, Parser/asdl_c.py shouldn't be included. Here's the correct patch
--
Added file: http://bugs.python.org/file46103/issue29082.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
I finally get Windows builds working. Here's the patch.
--
Added file: http://bugs.python.org/file46102/issue29082.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
Removed file:
http://bugs.python.org/file46055/LoadLibrary_revert_arg_parsing.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Chi Hsuan Yen added the comment:
Change this line:
export CFLAGS="-I/usr/local/Cellar/openssl/1.0.2j/include/openssl"
into:
export CFLAGS="-I/usr/local/Cellar/openssl/1.0.2j/include"
--
___
Python tracker <rep...
Chi Hsuan Yen added the comment:
Ah, things are quite the opposite :)
You have to set CFLAGS and LDFLAGS so that setup.py can find openssl headers
and libraries from Homebrew. For example:
export CFLAGS="-I/usr/local/opt/openssl/include"
export LDFLAGS="-L/usr/local/
Chi Hsuan Yen added the comment:
Did you set CFLAGS and LDFLAGS?
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
Sorry, but I'm afraid of being unable to test it. I tried to setup a Windows
build environment for 2.x but failed. (I've once successfully built 3.x on
Windows for issue25939, but things seems different now :(
--
keywords: +patch
Added file:
http
New submission from Chi Hsuan Yen:
In issue27330, there's one more change besides fixing possible memory leaks. In
LoadLibrary function of _ctypes: [1]
-if (!PyArg_ParseTuple(args, "O|O:LoadLibrary", , ))
+if (!PyArg_ParseTuple(args, "S|O:LoadLibrary", , ))
Befo
Chi Hsuan Yen added the comment:
> Would it be possible to not add this option for third party extensions?
Good suggestion. Just use $CFLAGS_NODIST instead of $BASECFLAGS.
--
Added file:
http://bugs.python.org/file46036/prohibit-implicit-function-declarations.pa
Chi Hsuan Yen added the comment:
(Re-use the existing issue)
Here's a patch that tries to add -Werror=implicit-function-declaration to
$BASECFLAGS.
This is useful for cross-compiling. When a function is missing, the error jumps
out during the build time rather than runtime.
Tested
New submission from Chi Hsuan Yen:
Remove an extra *
The typo is there in 3.5~3.7 branches. 2.7 branch does not have this example.
Nosy the two major commiters to Python/errors.c
--
assignee: docs@python
components: Documentation
files: PyErr_Fetch-fix.patch
keywords: patch
messages
New submission from Chi Hsuan Yen:
Here are the two examples I found confusing when playing with f-strings. The
first one involves with a NameError:
$ cat test2
f'''
{
FOO
}
'''
$ python3.7m test2
Traceback (most recent call last):
File "test2", line 5, in
'''
NameError:
Chi Hsuan Yen added the comment:
Thanks for compiling up necessary changes for NDK r14! Seems that indicates
future Python versions will require at least NDK r14 to build?
Another headache from unified headers is that it requires different --sysroot
in compilation and linking. Currently
Chi Hsuan Yen added the comment:
FYI: Since Android NDK r14 beta1, F_LOCK is defined in unified headers. [1] In
$ANDROID_NDK/sysroot/usr/include/bits/lockf.h:
#define F_ULOCK 0
#define F_LOCK 1
#define F_TLOCK 2
#define F_TEST 3
[1]
https://android.googlesource.com/platform/ndk.git/+/master
Chi Hsuan Yen added the comment:
Sorry Crys, I misclicked on SSL and I don't have the permission to revert it :/
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Chi Hsuan Yen added the comment:
numpy is not part of Python. Please report this to http://www.numpy.org/
--
assignee: -> christian.heimes
components: +SSL
nosy: +Chi Hsuan Yen, christian.heimes
___
Python tracker <rep...@bugs.python.org&
Chi Hsuan Yen added the comment:
I'm afraid that the sentence "wcscoll/wcsxfrm have known bugs" is misleading
for people who are not quite familiar with Android. The actual cause is that
BioniC's setlocale() behaves differently than other platforms. Most
implementations re
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28180>
___
_
Chi Hsuan Yen added the comment:
Seems there are quite a few typos/copy-paste errors in the original
steps-to-reproduce. Here are my steps on macOS:
$ ./python-build/python.exe -m venv 'aaa bbb'
$ source ./aaa\ bbb/bin/activate
$ pip
zsh: /Users/yen/tmp/aaa bbb/bin/pip: bad interpreter
Chi Hsuan Yen added the comment:
Modify target versions to bugfix and feature branches
--
versions: +Python 3.7 -Python 2.6, Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Changes by Chi Hsuan Yen <yan12...@gmail.com>:
--
nosy: +Chi Hsuan Yen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27400>
___
_
Chi Hsuan Yen added the comment:
Can you import _signal? And what's the output of dir(_signal)?
Another possibility is that there's another signal.py in the search path. Could
you also paste the output of repr(signal)?
By the way, here on Arch Linux, both signal.SIGINT and signal.SIGALRM
Chi Hsuan Yen added the comment:
Sorry I didn't read your patch carefully and it's surprising for me that you
didn't remove/modify this line in configure.ac:
CPPFLAGS="$CPPFLAGS -I/usr/include/ncursesw"
With this line left there, feature detections for _curses are broken as
./confi
Chi Hsuan Yen added the comment:
@xdegaye: no-path-to-ncursesw.patch fixes a problem yet introducing a new one.
With that patch auto-detection of ncurses include files are broken. Now users
have to specify the path manually even for native builds
Chi Hsuan Yen added the comment:
xdegaye's explanation is incorrect. The actual scene is much more complicated.
First, let me explain why things may be broken. The wrong directory is included
only if all of the following conditions are met:
1. PYTHON_FOR_BUILD is not installed with --prefix
Chi Hsuan Yen added the comment:
> The only change that is needed here is to not include /usr/include/ncursesw
> in setup.py when cross compiling
No. Lots of codes in _cursesmodule.c need to know whether it's ncursesw,
ncurses, or SysV's curses. For example: (segments below are from unp
1 - 100 of 289 matches
Mail list logo
