[issue23654] infinite loop in faulthandler._stack_overflow
Matt Frank added the comment: This is a patch that turns off the Intel Compiler's optimization for the stack_overflow() function. It turns out that icc doesn't support gcc's __attribute__((optimize(no-optimize-sibling-calls))). Instead I used an ifdef'd intel-specific pragma that turns off optimization completely for just this function, and just for the intel compiler. This particular pragma has the benefit that it should also work with the Intel compiler on Windows without needing further ifdefs. -- Added file: http://bugs.python.org/file38658/icc-stackoverflow.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23654 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23654] infinite loop in faulthandler._stack_overflow
Matt Frank added the comment: Yes, this is currently only a problem with the Intel compiler. The writes to buffer[] are dead (provably won't be ever used) at the point that the recursive call occurs. Actually gcc and llvm can figure this out. Thus all the space allocated for the first call can be reused by every subsequent call. The analysis that icc is doing that gcc and clang are not yet doing has to do with the pointer to depth. I believe icc is able to determine that depth doesn't point into buffer where gcc and clang aren't sure that this is the case. (If you change stack_overflow() so that depth is passed in and returned by value then gcc also does the tail optimization.) volatile doesn't disable the optimization. I think in this case it is too easy to determine that buffer is on the stack, and both buffer and sp are dead by the time of the recursive call. It occurs to me that the right way to deal with this is with __attribute__ ((optimize (no-optimize-sibling-calls))) on the function where it matters (stack_overflow()). I'm working on a solution (need to test whether the compiler supports attributes and etc.) and will post it ASAP. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23654 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23652] ifdef uses of EPOLLxxx macros so we can compile on systems that don't have them
New submission from Matt Frank: With the LSB (Linux Standard Base) headers for libc Modules/selectmodule.c fails to compile because we have code that uses EPOLLRDNORM, EPOLLRDBAND, EPOLLWRNORM and EPOLLMSG without first checking that they are defined. The patch wraps the five uses of PyModule_AddIntMacro in #ifdefs, following exactly the same pattern that is used for the POLLRDNORM, POLLRDBAND, POLLWRNORM, POLLMSG macros 30 lines earlier in selectmodule.c. The only documentation I can find for these five macros from Linux is (a) in the Python documentation for the select module! (https://docs.python.org/3.4/library/select.html#edge-and-level-trigger-polling-epoll-objects) and (b) on this StackOverflow answer: http://stackoverflow.com/a/27143672/2209313. They are not described on http://man7.org/linux/man-pages/man2/epoll_ctl.2.html (where the rest of the EPOLL macros are defined), nor at http://linux.die.net/man/4/epoll. As explained by the StackOverflow answer they actually are described (indirectly) by http://man7.org/linux/man-pages/man2/poll.2.html. Nor are these macros in the Linux Foundation's LSB database: http://www.linuxbase.org/navigator/browse/headgroup.php?cmd=list-byheadgroupHGid=1398. Obviously almost all modern Linuxes have these macros, so we should keep them, but we should also compile with the LSB headers (since compiling and linking against the LSB SDK (http://www.linuxfoundation.org/collaborate/workgroups/lsb/group) is one of the easiest ways to produce a Python binary that will actually run on most important supported Linux distros (e.g., RHEL 5). http://man7.org/linux/man-pages/man7/epoll.7.html, -- components: Build files: epoll-macros-patch.diff keywords: patch messages: 237984 nosy: WanderingLogic priority: normal severity: normal status: open title: ifdef uses of EPOLLxxx macros so we can compile on systems that don't have them versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38461/epoll-macros-patch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23652 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23652] ifdef uses of EPOLLxxx macros so we can compile on systems that don't have them
Changes by Matt Frank matthew.i.fr...@intel.com: -- type: - compile error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23652 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23654] infinite loop in faulthandler._stack_overflow
New submission from Matt Frank: When the faulthandler module is compiled at -O3 (the default for non-debug builds) with a compiler that does tailcall optimization the Modules/faulthandler.c:stack_overflow() function may become an infinite loop that does not expand the stack. This puts the interpreter into an infinite loop with 100% CPU utilization that won't respond to SIGINT. (But sending SIGTERM will get it to exit.) The Intel compiler (15.0.1 on Linux) seems to be able to prove this optimization safe. (And thus cause the function to turn into an infinite loop.) While gcc 4.8.2 and clang 3.4.2 do not currently optimize this call (because their pointer analysis isn't quite strong enough to deal with the pointer to the depth argument), there's no guarantee that they won't be able to optimize it in their next versions. This patch adds a test between the recursive call and the return statement which makes it not a tail call. -- components: Extension Modules files: faulthandler-infloop.patch keywords: patch messages: 237993 nosy: WanderingLogic priority: normal severity: normal status: open title: infinite loop in faulthandler._stack_overflow type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38463/faulthandler-infloop.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23654 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
Matt Frank added the comment: Apologies. That last patch includes diffs to generated files (configure and pyconfig.h.in). This version just patches Modules/pwdmodule.c and configure.ac. After applying the patch please run autoheader and autoconf to correctly regenerate configure and pyconfig.h.in. -- Added file: http://bugs.python.org/file37930/pw_gecos-field-workaround-with-config_ac-mods.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16353] add function to os module for getting path to default shell
Matt Frank added the comment: In msg174930 Christian Heimes (christian.heimes) wrote: I've tested confstr(CS_PATH) on Linux, Mac OS X, Solaris, HP-UX and BSD. It works and the path to `sh` is always included. In msg230713 Ned Deily(ned.deily) wrote: ignore Lib/macpath.py. [...] OS X uses Lib/posixpath.py. These two messages have convinced me that the correct approach is to kick the can down the road. I will file a new issue and patch to fix os.defpath (by initializing os.defpath by calling confstr(CS_PATH)). Then I will file a new issue and patch that will define a reasonable os.confstr() for platforms where HAVE_CONFSTR is not defined. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16353 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16353] add function to os module for getting path to default shell
Matt Frank added the comment:
In msg230720 Akira Li (akira) wrote:
os.defpath is supposed to be ':'+CS_PATH, e.g., look at glibc (C library
used on Linux) sysdeps/posix/spawni.c I don't know whether it is
possible to change CS_PATH without recompiling every statically linked
executable on a system, sysdeps/unix/confstr.h:
#define CS_PATH /bin:/usr/bin
Though this issue is about the path to the standard shell sh/cmd.exe.
It is not about os.defpath.
I understand this issue is about the path to the standard shell.
My argument is that os.defpath is the wrong tool for finding that
path, and os.confstr('CS_PATH') is the correct tool, as you originally
suggested in msg224514.
The patch [1] has tests. Have you tried to run them?
The tests *pass* at least on one system ;)
[...]
os.get_shell_executable() does not use cwd. Neither the documentation
nor the code in the patch suggest that.
I ran the tests (and the entire Python test suite) before I wrote my
first message. But you didn't test what happens when there is a bogus
'sh' somewhere along the path. You also have a bug in your path
searching loop that interprets an empty element on the path as /.
Here's the current failure mode:
Go to root on your Posix system. With su or sudo create an
executable file named sh. (for example cd /; sudo touch sh; sudo
chmod +x sh). Then go back to your python interpreter (with the
patch applied) and run os.get_shell_executable(). The returned
result will be '/sh'.
The loop _should_ be treating empty path elements as current working
directory. (In the glibc sysdeps/posix/spawni.c file you pointed to
look around line 281, by the comment that says /* Two adjacent
colons, or a colon at the beginning or the end of 'PATH' means to
search the current directory.*/)
But if you fix the loop to iterate over the path correctly (including
'cwd') then you will find that putting an executable named 'sh' in the
current working directory will make os.get_shell_executable() return
the sh in the current working directory (because os.defpath says it
should).
Note also, that glibc's spawni() uses two different default paths.
One is for if the user didn't specify their PATH variable (that's the
one where they use :/bin:/usr/bin) and a completely different (built
in path is used in the spawn*p* version) if it turns out that the file
is a script that needs to run under the system sh. (On line 290 they
call maybe_script_execute(), which calls script_execute(), which uses
_PATH_BSHELL.)
os.defpath is the default search path used by exec*p* and spawn*p*
i.e., if os.defpath is incorrect for these system then os.exec*p* and
os.spawn*p* functions could also be broken.
I'll look into it.
I don't remember exactly the motivation to use os.defpath instead of
os.confstr('CS_PATH').
The motivation was in msg224514. You wrote:
In the absense of os.confstr('CS_PATH') on Android (msg175006),
os.defpath seems appropriate than os.environ['PATH'] to expand 'sh'
basename to the full path to be used by subprocess later.
But os.defpath doesn't work on Android either (because it is hardcoded
to ':/bin:/usr/bin').
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16353
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
Matt Frank added the comment: Assuming issue16353 is fixed using http://bugs.python.org/file36196/os.get_shell_executable.patch the appropriate way to find the path to the default shell is by calling os.get_shell_executable(). This is the 1-liner patch that uses os.get_shell_executable() in Popen() instead of the hard-coded string /bin/sh. -- keywords: +patch Added file: http://bugs.python.org/file37139/popen-no-hardcode-bin-sh.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22809] Include/graminit.h and Python/graminit.c always rebuilt (breaks cross builds)
New submission from Matt Frank: changeset 92496:c2a53aa27cad (issue22359) broke cross builds. (Now make touch; make always tries to rebuild Include/graminit.h and Python/graminit.c by running pgen. But pgen is a host executable and won't run on the build machine during a cross-build.) I think the problem is here, around Makefile.pre.in line 750. The dependency was on PGENSRCS and is now on PGEN. Will changing it back to PGENSRCS break something else? @@ -745,15 +746,13 @@ $(IO_OBJS): $(IO_H) -$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGENSRCS) +$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN) -- components: Build, Cross-Build messages: 230765 nosy: WanderingLogic priority: normal severity: normal status: open title: Include/graminit.h and Python/graminit.c always rebuilt (breaks cross builds) versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22809 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Matt Frank added the comment: Sorry, I'm complaining. Cross builds broke. Please see issue22809. -- nosy: +WanderingLogic ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +WanderingLogic ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16255 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16353] add function to os module for getting path to default shell
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +WanderingLogic ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16353 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5717] os.defpath includes unix /bin on windows
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +WanderingLogic ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5717 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16353] add function to os module for getting path to default shell
Matt Frank added the comment:
Unfortunately os.defpath seems to be hardcoded. And hardcoded to the wrong
value on every system I have looked at, including Linux.
Lib/posixpath.py sets defpath=':/bin:/usr/bin' which is _not_ what `getconf
CS_PATH` returns on my Linux (the extra ':' at the beginning means include the
cwd[1] which is almost certainly not what anyone wants.) The hardcoded value
'/bin:/usr/bin' would also be wrong for Solaris and AIX installations that are
trying to be POSIX (I think they use /usr/xpg4/bin/sh).
Meanwhile Lib/macpath.py sets defpath=':', which is also almost certainly
wrong. (I don't have a Mac and have never programmed one, but StackOverflow[2]
indicates that one should use `path_helper` (which in turn gets the default
value by reading it from the files in /etc/paths.d))[3] So it seems likely
that this patch breaks Popen() on MacOS (unless, perhaps, a path of ':' means
something special on Mac?).
And Lib/ntpath.py sets defpath='.;C:\\bin', which doesn't resemble a path that
even works (as pointed out in now closed http://bugs.python.org/issue5717).
(The correct value may be
'%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\'.)
So I don't know where to go next. I'm happy to cook up a different patch, but
I have no idea what it should be. Here are some possibilities:
1. Kick the can down the road: file a new bug against os.defpath and (somehow)
fix Lib/*path.py so they do something more reasonable in more cases. One of
which might be to have posixpath.py try to call os.confstr() (and then,
perhaps, special-code something in Modules/posixmodule.c in the case that
HAVE_CONFSTR is not defined.)
2. Modify @akira's patch to call os.confstr('CS_PATH') instead of os.defpath,
and then deal with the fact that very few systems actually implement confstr()
(perhaps by special-coding something in Modules/posixmodule.c as described
above.)
3. Modify this patch to fall back to `PATH` if `sh` can't be found on
os.defpath (or os.confstr('CS_PATH') fails).
[1] `man bash` on Linux, search for the description of the PATH variable.
(e.g., http://man7.org/linux/man-pages/man1/bash.1.html)
[2]
http://stackoverflow.com/questions/9832770/where-is-the-default-terminal-path-located-on-mac
[3]
https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/path_helper.8.html
[4]
http://superuser.com/questions/124239/what-is-the-default-path-environment-variable-setting-on-fresh-install-of-window
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16353
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5717] os.defpath includes unix /bin on windows
Matt Frank added the comment:
os.defpath also seems wrong on Mac (':') and Linux (':/bin:/bin/sh'. The extra
':' at the beginning means the same thing as '.:/bin:/bin/sh' which is probably
a security problem.
I just started up discussion on http://bugs.python.org/issue16353 (which may
require a correct os.defpath).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5717
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22747] Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined
Matt Frank added the comment: My platform is the Android command-line shell. Essentially it is like an embedded linux platform with a very quirky partially implemented libc (not glibc). It has no langinfo.h and while it has locale.h, the implementations of setlocale() and localeconv() do nothing (and return null). The wcstombs() and mbstowcs() functions are both mapped to strncpy(). As was the original intent of utf-8, since the Linux kernel (and most supported file systems) store filenames as null-terminated byte strings, utf-8 encoded file names work with software that assumes that the encoding is utf-8 (for example the xterm program that I'm using to ssh into the machine) (for another example, the Dalvik JVM that runs user-apps.) My intent with this tracker is to make it slightly easier for people who have libc like Android where the locale support is completely broken and really only 8-bit ascii is supported to get something reasonable to compile and run, while simultaneously not breaking the supported platforms. If you look at what Kivy and Py4A have done, they basically have patches all over the main interpreter that, once applied, make the interpreter not work on any supported platform. I'm trying to avoid that approach. Two possibilities for this particular part of the interpreter are to implement option (3) above, or to implement option (4) above. Option (3) is preferable in the long run, but option(4) is a much smaller change (as long as it does consistently with the decision of tracker 8610.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22747 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22747] Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined
Matt Frank added the comment: I am working on using my resources at Intel to put some pressure on Google to fix some of the (many) problems in the Bionic libc. I have a sort of polyfill library that implements locale.h, langinfo.h, as well as the structure definitions for wchar.h, and it borrows the utf8 mbs*towcs() and wcs*tombs() implementations from FreeBSD. It implements a setlocale() and nl_langinfo() that starts in locale C, fakes it as though the user's envvars are set to C.UTF-8 (so if you call setlocale(LC_ALL, ) the encoding is changed to UTF-8). But Bionic has been broken for many years, and it will most likely take many more years before I (or somebody) can arrange the right set of things to get it fixed. It is not really in Google's interest to have people writing non-JVM code, so they seem to only grudgingly support it, their JVM APIs are the walled garden that keeps apps sticky to their platform, while allowing them to quickly switch to new processor architectures if they need to. But all of that is not really germane to this bug. The fact is that cpython, when compiled for a system with no langinfo.h creates an executable that does nothing but crash. What other systems (other than Android) have no langinfo.h? (Alternatively, why has this feature-test been in configure.ac for many years?) If the solution for Android is it's android's bug and they should fix it then shouldn't we remove all the #ifdef HAVE_LANGINFO_H tests from the code and just let compilation fail on systems that don't have langinfo.h? That is option (1) or (2) that I suggested above. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22747 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21668] The select and time modules uses libm functions without linking against it
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +WanderingLogic Added file: http://bugs.python.org/file37041/audioop_ctypes_test_link_with_libm.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21668] The select and time modules uses libm functions without linking against it
Matt Frank added the comment: Additionally, * audioop calls floor() * _ctypes_test calls sqrt() Patch attached. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21668] The select and time modules uses libm functions without linking against it
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +freakboy3742 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +freakboy3742 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21668] The select and time modules uses libm functions without linking against it
Matt Frank added the comment: audioop_ctypes_test_link_with_libm.patch + libraries=['m']) Why not using math_libs here? math_libs is defined in detect_modules(). But the _ctypes_test extension is defined in a different function: detect_ctypes(). The other option, would be to define math_libs=['m'] directly above this line and then use it once. I didn't think that added clarity, but I'd be happy to do it that way if it fits better with standard style. It would also be nice to add a comment explaining why libm is needed in each module. Done. Can someone please combine both patches? Done. -- Added file: http://bugs.python.org/file37042/time_select_audioop_ctypes_test_link_with_libm.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22747] Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined
New submission from Matt Frank: On systems where configure is unable to find langinfo.h (or where nl_langinfo() is not defined), configure undefines HAVE_LANGINFO_H in pyconfig.h. Then in pythonrun.c:get_locale_encoding() the call to nl_langinfo() is wrapped in an #ifdef, but the #else path on the ifdef does a PyErr_SetNone(PyExc_NotImplementedError) and returns NULL, which causes initfsencoding() to fail with the message Py_Initialize: Unable to get the locale encoding, which causes the interpreter to abort. I'm confused because http://bugs.python.org/issue8610 (from 2010) seems to have come down on the side of deciding that nl_langinfo() failures should be treated as implicitly returning either ASCII or UTF-8 (I'm not sure which). But maybe that was for a different part of the interpreter? In any case there are 4 choices here, all of which are preferable to what we are doing now. 1. Fail during configure. If we can't even start the interpreter, then why waste the users time with the build? 2. Fail during compilation. The #else path could contain #error Python only works on systems where nl_langinfo() is correctly implemented. Again, this would be far preferable to failing only once the user has finished the install and tries to get the interpreter prompt. 3. Implement our own python_nl_langinfo() that we fall back on when the system one doesn't exist. (It could, for example, return ASCII (or ANSI_X3.4-1968) to start with, and UTF-8 after we see a call to setlocale(LC_CTYPE, ) or setlocale(LC_ALL, ). 4. just return the string ASCII. The attached patch does the last. I'm willing to try to write the patch for choice (3) if that's what you'd prefer. (I have an implementation that does (3) for systems that also don't have setlocale() implemented, but I don't yet know how to do it if nl_langinfo() doesn't exist but setlocale() does.) -- components: Interpreter Core files: no_langinfo_during_init.patch keywords: patch messages: 230106 nosy: Arfrever, WanderingLogic, haypo, lemburg, loewis, pitrou priority: normal severity: normal status: open title: Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37046/no_langinfo_during_init.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22747 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
Changes by Matt Frank matthew.i.fr...@intel.com: -- nosy: +WanderingLogic ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
Matt Frank added the comment: Here is shiz's patch extended with the addition to configure.ac. I added the variable HAVE_PASSWD_GECOS_FIELD and the appropriate tests. Luckily this very problem (missing pw_gecos field) is the example used in the autoconf manual (https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Generic-Structures.html#Generic-Structures). (Otherwise I would have been as lost as I usually am with autoconf.) -- Added file: http://bugs.python.org/file37009/pw_gecos-field-workaround-with-config_ac-mods.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
