[issue42341] xml.dom.minidom parsing omits Text nodes in top level
New submission from Mike Frysinger :
$ python3
Python 3.8.5 (default, Aug 2 2020, 15:09:07)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.dom import minidom
# Lets parse a simple XML file with comment & text nodes in the top level.
>>> dom = minidom.parseString('>> encoding="UTF-8"?>\n\n\n\n\n\n\n')
# Where did those newlines get to outside of ?
>>> dom.toxml()
'\n\n\n'
# No Text nodes in the root list :(.
>>> dom.childNodes
[, , ]
# But they all exist fine under .
>>> dom.childNodes[2].childNodes
[, , ,
, ]
--
components: XML
messages: 380872
nosy: vapier
priority: normal
severity: normal
status: open
title: xml.dom.minidom parsing omits Text nodes in top level
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue42341>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23436] xml.dom.minidom.Element.ownerDocument is hidden
Change by Mike Frysinger : -- title: xml.dom.minidom.Element.ownerDocument is hiden -> xml.dom.minidom.Element.ownerDocument is hidden ___ Python tracker <https://bugs.python.org/issue23436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42253] xml.dom.minidom.rst missing standalone documentation
Change by Mike Frysinger : -- assignee: -> docs@python components: +Documentation nosy: +docs@python title: xml.dom.minidom.rst missed informations -> xml.dom.minidom.rst missing standalone documentation ___ Python tracker <https://bugs.python.org/issue42253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39857] subprocess.run: add an extra_env kwarg to complement existing env kwarg
Mike Frysinger added the comment: personally i still like having the extra_env setting explicitly broken out, but i agree that those operators help ease the majority of the pain. i hadn't come across them before as they aren't in Python 2. i wouldn't be upset if people declined the FR considering those options will be available in Python 3.9+. thx for the tips. -- ___ Python tracker <https://bugs.python.org/issue39857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39857] subprocess.run: add an extra_env kwarg to complement existing env kwarg
New submission from Mike Frysinger :
a common idiom i run into is wanting to add/set one or two env vars when
running a command via subprocess. the only thing the API allows currently is
inherting the current environment, or specifying the complete environment.
this means a lot of copying & pasting of the pattern:
env = os.environ.copy()
env['FOO'] = ...
env['BAR'] = ...
subprocess.run(..., env=env, ...)
it would nice if we could simply express this incremental behavior:
subprocess.run(..., extra_env={'FOO': ..., 'BAR': ...}, ...)
then the subprocess API would take care of copying & merging.
if extra_env:
assert env is None
env = os.environ.copy()
env.update(extra_env)
this is akin to subprocess.run's capture_output shortcut.
it's unclear to me whether this would be in both subprocess.Popen &
subprocess.run, or only subprocess.run. it seems like subprocess.Popen elides
convenience APIs.
--
components: Library (Lib)
messages: 363413
nosy: vapier
priority: normal
severity: normal
status: open
title: subprocess.run: add an extra_env kwarg to complement existing env kwarg
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39857>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3548] subprocess.pipe function
Mike Frysinger added the comment: this would have been nice to have more than once in my personal projects, and in build/infra tooling for Chromium OS. our alternatives so far have been the obvious ones: use subprocess.run to capture & return the output, then manually feed that as the input to the next command, and so on. we know it has obvious overhead so we've avoided with large output. we strongly discourage/ban attempts to write shell code, so the vast majority of our commands are argv style (list of strings), so the pipes module wouldn't help us. handling of SIGPIPE tends to be where things get tricky. that'll have to be handled by the API explicitly i think. -- nosy: +vapier ___ Python tracker <https://bugs.python.org/issue3548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid() does not
Mike Frysinger added the comment: if threading.active_count() returns 1, then you know there's one thread, and you're it, so it's not racey, and a lock ins't needed. thinking a bit more, what if the code just use a recursive lock ? that would restore the single threaded status quo without overly complicating the code. thinking a bit more, i think you're right that this is inherently racy, but not because using the APIs in async context isn't permissible. if a signal is delivered after Popen.wait() finishes the OS waitpid call, but before it releases the lock, then the child state is not recoverable from the signal handler. in our case, we're using the signal handler to kill the process, and we want to make sure it's exited, so being able to get the exact exit status is not important to us, just making sure we can detect when the process is gone. -- ___ Python tracker <https://bugs.python.org/issue25960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid() does not
Mike Frysinger added the comment: to be clear, there is no Python or OS restriction that you're aware of for your earlier statement ? you just want to make it into a new Popen restriction that didn't previously exist ? we came across this bug as we upgraded our existing Python 2.7 codebase to Python 3.6. so even if it's "been this way for a while" (which is to say, since the 3.4.1 release), at least some people are going to be coming across this for the first time as they migrate. if the popen APIs aren't going to handle this correctly (check threading.active_count?), can we at least get a knob to disable it or class methods we can stub out ? we never use threads, so having popen add support for a runtime mode we never utilize is kind of annoying. for now i'm defining a custom subprocess.Popen class to break the lock, but it's kind of terrible to have to access _waitpid_lock outside of the subprocess module. -- ___ Python tracker <https://bugs.python.org/issue25960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid() does not
Mike Frysinger added the comment: > fundamentally: this shouldn't work anyways. > > You are calling wait() from a signal handler. > That is a blocking operation. > You cannot do that from a signal handler. what definition/spec are you referring to here ? is this a Python limitation ? i don't see any mention in the Python documentation on the subject: https://docs.python.org/3/library/signal.html maybe you meant this as an OS limitation ? it's certainly not a POSIX limitation as it's quite clear on the subject: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html > The following table defines a set of functions that shall be > async-signal-safe. Therefore, applications can call them, without > restriction, from signal-catching functions. > wait() > waitpid() in general, the idea that a signal handler "cannot block" is weird. i guess you're saying that anything that involves the OS is forbidden ? there's no guarantee something as simple as a file open() or close() won't block, or really any syscall at all. i bisected a similar testcase from the OP down ... python 3.4.0 works, but 3.4.1 fails. looks like it's due to this change: https://github.com/python/cpython/commit/d65ba51e245ffdd155bc1e7b8884fc943048111f Author: Gregory P. Smith Date: Wed Apr 23 00:27:17 2014 -0700 subprocess's Popen.wait() is now thread safe so that multiple threads may be calling wait() or poll() on a Popen instance at the same time without losing the Popen.returncode value. Fixes issue #21291. -- nosy: +vapier ___ Python tracker <https://bugs.python.org/issue25960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.
Mike Frysinger added the comment: that's highlighting the SemLock._make_name func which doesn't have retry logic in it. did you mean to highlight SemLock.__init__ which has a retry loop that looks similar to the C code ? https://github.com/python/cpython/blob/a1c249c40517917d2e0971d55aea8d14a44b2cc8/Lib/multiprocessing/synchronize.py#L55-L65 -- ___ Python tracker <https://bugs.python.org/issue24303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.
Mike Frysinger added the comment: it does seem like the patch was never applied to any python 3 branch :/ -- ___ Python tracker <https://bugs.python.org/issue24303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31822] Document that urllib.parse.{Defrag, Split, Parse}Result are namedtuples
Mike Frysinger <vap...@users.sourceforge.net> added the comment: specifically, the docs for these classes: https://docs.python.org/2/library/urlparse.html#results-of-urlparse-and-urlsplit https://docs.python.org/3/library/urllib.parse.html#urlparse-result-object > The result objects from the urlparse() and urlsplit() functions are subclasses > of the tuple type. These subclasses add the attributes described in those > functions, as well as provide an additional method: > ... > class urlparse.SplitResult(scheme, netloc, path, query, fragment) > Concrete class for urlsplit() results. changing "subclasses of the tuple type" to "subclasses of collections.namedtuples" would be great. also adding hints to use _replace to update values would be great :). -- nosy: +vapier ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid -> process mapping.
Mike Frysinger added the comment: i don't feel strongly about either version -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25397] improve ac_cv_have_long_long_format GCC fallback
New submission from Mike Frysinger: the ac_cv_have_long_long_format test has a nice compile-time fallback for gcc based compilers: CFLAGS="$CFLAGS -Werror -Wformat" AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #include #include ]], [[ char *buffer; sprintf(buffer, "%lld", (long long)123); sprintf(buffer, "%lld", (long long)-123); sprintf(buffer, "%llu", (unsigned long long)123); ]])], ac_cv_have_long_long_format=yes ) unfortunately, this turns on the global -Werror flag in order to check things. that means if the code triggers unrelated warnings, the test still fails ;(. this comes up w/bionic which complains about unsafe use of the sprintf function, and can come up in general in this code because buffer is not initialized :). the good news is that gcc-4.2 has supported a directed -Werror=format option. https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Warning-Options.html so instead of using -Werror -Wformat, you could use -Werror=format. the downside is that the fallback no longer works with <=gcc-4.1, but maybe that's ok considering gcc-4.2 was released May 2007 (almost 9 years ago) ? note: this also applies to various other tests in the configure file. NB: landing a fix in py3.5+ (and ignoring 3.[0-4]) is fine, but please also to fix py2.7 :) -- components: Cross-Build messages: 252968 nosy: vapier priority: normal severity: normal status: open title: improve ac_cv_have_long_long_format GCC fallback type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19372] configure and compile problems with older CentOS releases
Mike Frysinger added the comment: time to close then ? -- nosy: +vapier ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19372> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18148] Make of Python 3.2.2 fails on Solaris SPARC
Mike Frysinger added the comment: if the current builds fail, please make sure to include the config.log file as that includes a cross-compile test for this setting -- nosy: +vapier ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24935] LDSHARED is not set according when CC is set.
Changes by Mike Frysinger vap...@users.sourceforge.net: -- nosy: +vapier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24935] LDSHARED is not set according when CC is set.
Mike Frysinger added the comment: looks like the patch was reversed, but otherwise should be clear what we're going for -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid - process mapping.
Mike Frysinger added the comment: also, it looks like this bug is in python-3.3. not sure what the status of that branch is, but maybe the backport from 3.4 would be easy ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid - process mapping.
Mike Frysinger added the comment: the original report on our side w/bunches of tracebacks: http://crbug.com/481223 with that traceback in hand, it's pretty trivial to write a reproduction :). attached! i couldn't figure out how to make it work w/out completely execing a new python instance. i suspect the internals were communicating and thus defeating the race. the unshare() might need some checks so that it skips on older kernels or ones with pidns support disabled. but i don't have any such system anymore ;). if all goes well, it should fail fairly quickly: $ python3.3 ./test.py Traceback (most recent call last): File string, line 1, in module File /usr/lib64/python3.3/multiprocessing/__init__.py, line 187, in Event return Event() File /usr/lib64/python3.3/multiprocessing/synchronize.py, line 293, in __init__ self._cond = Condition(Lock()) File /usr/lib64/python3.3/multiprocessing/synchronize.py, line 174, in __init__ self._wait_semaphore = Semaphore(0) File /usr/lib64/python3.3/multiprocessing/synchronize.py, line 84, in __init__ SemLock.__init__(self, SEMAPHORE, value, SEM_VALUE_MAX) File /usr/lib64/python3.3/multiprocessing/synchronize.py, line 48, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) FileExistsError: [Errno 17] File exists failed and doesn't take that long to pass: $ time python3.4 ./test-issue24303.py passed! real0m1.715s -- Added file: http://bugs.python.org/file39594/test-issue24303.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid - process mapping.
Mike Frysinger added the comment: we hit this problem daily in Chromium OS's build farm because we use pid namespaces heavily -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24303] OSError 17 due to _multiprocessing/semaphore.c assuming a one-to-one Pid - process mapping.
Changes by Mike Frysinger vap...@users.sourceforge.net: -- nosy: +vapier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21664] multiprocessing leaks temporary directories pymp-xxx
Mike Frysinger added the comment: this has been fixed between py3.2 and py3.3: http://hg.python.org/cpython/diff/831ae71d0bdc/Lib/multiprocessing/managers.py so just asking for that to be backported to the py2.x branch :) -- nosy: +vapier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15506] configure should use PKG_PROG_PKG_CONFIG
New submission from Mike Frysinger: the current configure script open codes the pkg-config look up: AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) rather than using the standard macro from pkg-config's own pkg.m4: PKG_PROG_PKG_CONFIG this causes the build env to not operate exactly like other pkg-config autoconf builds :( simple fix: -AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) +PKG_PROG_PKG_CONFIG -- components: Build messages: 166915 nosy: vapier priority: normal severity: normal status: open title: configure should use PKG_PROG_PKG_CONFIG type: compile error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15000] _posixsubprocess module broken on x32
Mike Frysinger vap...@users.sourceforge.net added the comment: a uint64_t would fix it for x86_64, but break it most 32bit systems as sizeof(unsigned long) == 32bit for them -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15000] posixsubprocess module broken on x32
New submission from Mike Frysinger vap...@users.sourceforge.net: the direct call to the getdents syscall is broken on x32. there, the first two args are not unsigned long, but unsigned long long. patch attached to fix the issue. -- components: Extension Modules files: python-3.2.3-x32.patch keywords: patch messages: 162281 nosy: vapier priority: normal severity: normal status: open title: posixsubprocess module broken on x32 versions: Python 3.2 Added file: http://bugs.python.org/file25819/python-3.2.3-x32.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15000] posixsubprocess module broken on x32
Mike Frysinger vap...@users.sourceforge.net added the comment: $ echo | gcc -m32 -E -P -dD - | grep LP nothing $ echo | gcc -m64 -E -P -dD - | grep LP #define _LP64 1 #define __LP64__ 1 $ echo | gcc -mx32 -E -P -dD - | grep LP #define _ILP32 1 #define __ILP32__ 1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3754] cross-compilation support for python build
Changes by Mike Frysinger vap...@users.sourceforge.net: -- nosy: +vapier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Mike Frysinger vap...@users.sourceforge.net added the comment: i really dont understand your point. python uses autoconf and therefore any questions about python's usage of autoconf to accomplish cross-compiles is completely valid here. no one was asking for general autoconf help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Mike Frysinger vap...@users.sourceforge.net added the comment: AC_TRY_RUN is already documented: http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992 there are a bunch of distros out there (like OE and Gentoo) that have been maintaining cross-compile patches for python. i'm pretty sure the stuff in Gentoo works for 2.6.x, but i havent tried 3.1.x yet. ive given up on pushing to upstream as this bug (among others)) shows that such attempts go nowhere -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Mike Frysinger vap...@users.sourceforge.net added the comment: Gregory: there's no need to be a dick. i'm pointing out the obvious -- bugs have been open literally for *years* with zero assistance/feedback from anyone who can actually get things merged. people have posted patches, but no one has said xxx needs to be done in order to get merged. you havent posted anything here either (assuming you're someone who can actually get things merged and not just comment in a tracker). if you can at least do something with trackers, you should start by marking 1597850 as a dupe of this one. or you can simply prove my point by continuing to contribute nothing. the basic required changes are simple -- fix the few autoconf tests. getting automatic cross-detection (building a host python/pygen automatically) isnt nearly as important as long as people have a way to tell the build system to use a different python/pgen for build purposes. last i looked, these simple changes were pretty trivial to move across major versions of python. i fixed the chflags specific check a long time ago (as i imagine others have as well): http://sources.gentoo.org/dev-lang/python/files/python-2.6-chflags-cross.patch same goes for the printf %zd test: http://sources.gentoo.org/dev-lang/python/files/python-2.5-cross-printf.patch however, unless these trivial baby steps can be made, worrying about the next step (properly cross-compiling modules and such) is a complete waste of time as these require diving into the python-specific build system which does see a lot of churn over versions. -- nosy: +vapier ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Mike Frysinger vap...@users.sourceforge.net added the comment:
the chflags is specifically documented as needing a runtime test:
# On Tru64, chflags seems to be present, but calling it will
# exit Python
which is why i left the default of AC_TRY_RUN but cross-compile falls
back to a simple link test. btw, a compile test is not valid when
trying to see if a function exists. you'll get a successful compile
(and warning about implicit function), but no error because you didnt
finally link the object with the undefined reference.
somewhat similar are the compiler checks (profile/pthread/alias/etc...).
some compilers do different things when linking and compiling (like gcc
and -pthread), so sticking to a LINK in the fallback of the RUN is
better, although not always perfect. some flags are accepted/ignored by
compilers and issue only warnings about the unknown flags, not errors.
but this issue probably isnt worth worrying about considering the code
in there today suffers from this edge case (and if no one is
complaining, then forget about it).
in terms of making sure all AC_TRY_RUN's have cross-compile fallbacks, i
only worried about the ones that actually get exercised. the two i
posted fixes for are the only ones ive seen people (and myself) actively
hit.
the ipv6 should def have a LINK fallback, and it should try using
in6addr_any as that is often an exported symbol (which is missing when
ipv6 doesnt exist).
the double endian checks could easily be made into a compile test with a
creative grep. pick a double value that expands into a funky ascii
string and then grep the object file for a match. otherwise, a char
swapped ascii string indicates it's big endian.
the wchar/rshift signed tests can be made into a compile-only test by
creative use of arrays (like autoconf does now with compile sizeof() tests).
main() { char foo[(((wchar_t) -1) ((wchar_t) 0)) ? 1 : -1]; }
compilers will portably abort when array size is negative, and this
expression should be a constant.
i dont think any of the broken ones need to be sorted out as they
already have cross-compile fall backs and there isnt much to be done in
figuring out if the run time env is broken.
thanks Greg for the commits !
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1006238
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1006238] cross compile patch
Mike Frysinger vap...@users.sourceforge.net added the comment: Garrett: your configure method is overly complicated. all you need to do is set --build=binos_c3.4.3-p1.mips64-octeon-linux. autoconf will figure out all the other toolchain settings. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1006238 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
