[ python-Bugs-1633863 ] AIX: configure ignores $CC
Bugs item #1633863, was opened at 2007-01-12 09:46 Message generated for change (Comment added) made by smudd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX: configure ignores $CC Initial Comment: CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r": case $ac_sys_system in AIX*) CC=cc_r without_gcc=;; It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt". An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code. Regards, Johannes -- Comment By: Simon Mudd (smudd) Date: 2007-02-20 11:36 Message: Logged In: YES user_id=1724042 Originator: NO This issue also prevents trying to build Python with gcc on AIX which I am attempting at the moment. While trying to resolve my own issue I have applied the following dirty patch to the python-2.5 tar ball. The patch should allow you to set CC to a non standard value. # Patch to make Python work with AIX and OpenPKG. # # This patch is NOT complete. # - configure is not automatically recreated from configure.in # - The correct behaviour for AIX should be to use CC if set and # otherwise to look for cc_r, cc and gcc (not sure about the order). # Index: configure.in --- configure.in.orig 2007-02-19 15:19:32.0 +0100 +++ configure.in2007-02-19 15:21:35.0 +0100 @@ -346,8 +346,15 @@ without_gcc=$withval;; esac], [ case $ac_sys_system in - AIX*) CC=cc_r - without_gcc=;; + AIX*) + # set CC if not set already. + # - SHOULD enhance check to look for cc or gcc in case it + # is in the PATH. + if /usr/bin/test -z "$CC"; then + CC=cc_r + without_gcc= + fi + ;; BeOS*) case $BE_HOST_CPU in ppc) Index: configure *** configure.orig Tue Feb 20 10:14:18 2007 --- configure Tue Feb 20 10:15:23 2007 *** *** 1719,1726 else case $ac_sys_system in ! AIX*) CC=cc_r ! without_gcc=;; BeOS*) case $BE_HOST_CPU in ppc) --- 1719,1733 else case $ac_sys_system in ! AIX*) ! # set CC if not set already. ! # - SHOULD enhance check to look for cc or gcc in case it ! # is in the PATH. ! if /usr/bin/test -z "$CC"; then ! CC=cc_r ! without_gcc= ! fi ! ;; BeOS*) case $BE_HOST_CPU in ppc) -- Comment By: Johannes Abt (jabt) Date: 2007-01-30 14:07 Message: Logged In: YES user_id=1563402 Originator: YES Sorry about the C++ comments... all the C++ comments I have found concern Windows, PC or Darwin. I must have confused this with another project I have been compiling. Though there still the issue with setting $CC. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-19 06:47 Message: Logged In: YES user_id=33168 Originator: NO There shouldn't be any C++ comments in the Python code. If there are, it is a mistake. I did see some get removed recently. Could you let me know where you see the C++ comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1663329 ] subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Bugs item #1663329, was opened at 2007-02-19 11:17
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: H. von Bargen (hvbargen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess/popen close_fds perform poor if SC_OPEN_MAX is hi
Initial Comment:
If the value of sysconf("SC_OPEN_MAX") is high
and you try to start a subprocess with subprocess.py or os.popen2 with
close_fds=True, then starting the other process is very slow.
This boils down to the following code in subprocess.py:
def _close_fds(self, but):
for i in xrange(3, MAXFD):
if i == but:
continue
try:
os.close(i)
except:
pass
resp. the similar code in popen2.py:
def _run_child(self, cmd):
if isinstance(cmd, basestring):
cmd = ['/bin/sh', '-c', cmd]
for i in xrange(3, MAXFD):
try:
os.close(i)
except OSError:
pass
There has been an optimization already (range has been replaced by xrange to
reduce memory impact), but I think the problem is that for high values of
MAXFD, usually a high percentage of the os.close statements will fail, raising
an exception (which is an "expensive" operation).
It has been suggested already to add a C implementation called "rclose" or
"close_range" that tries to close all FDs in a given range (min, max) without
the overhead of Python exception handling.
I'd like emphasize that this is not a theoretical, but a real world problem:
We have a Python application in a production environment on Sun Solaris. Some
other software running on the same server needed a high value of 26 for
SC_OPEN_MAX (set with ulimit -n XXX or in some /etc/-file (don't know which
one).
Suddenly calling any other process with subprocess.Popen (..., close_fds=True)
now took 14 seconds (!) instead of some microseconds.
This caused a huge performance degradation, since the subprocess itself only
needs only a few seconds.
See also:
Patches item #1607087 "popen() slow on AIX due to large FOPEN_MAX value".
This contains a fix, but only for AIX - and I think the patch does not support
the "but" argument used in subprocess.py.
The correct solution should be coded in C, and should
do the same as the _close_fds routine in subprocess.py.
It could be optimized to make use of (operating-specific) system calls to close
all handles from (but+1) to MAX_FD with "closefrom" or "fcntl" as proposed in
the patch.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-21 00:45
Message:
Logged In: YES
user_id=21627
Originator: NO
Wouldn't it be simpler for you to just don't pass close_fds=True to popen?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1663329&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653121 ] Double free/corruption?
Bugs item #1653121, was opened at 2007-02-06 01:54 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jarek Zgoda (zgoda) Assigned to: Nobody/Anonymous (nobody) Summary: Double free/corruption? Initial Comment: Today I encountered a problem with system complaining on double free/corruption, but as I don't know C, I cann't say it's a problem with Python or with MySQLdb. Attached is a stack trace that I saw in screen session termination window. I am unable to reproduce this error, I tried few times, but it does not happen. If this is a MySQLdb (or even MySQL) problem, I'll report the bug as appriopriate, just let me know. The system is pretty standard FC4. Below is as some system information, let me know if I should provide you anything more. $ python Python 2.4.3 (#1, Jun 13 2006, 16:41:18) [GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2 $ uname -a Linux localhost 2.6.17-1.2139_FC4smp #1 SMP Fri Jun 23 21:12:13 EDT 2006 i686 i686 i386 GNU/Linux $ yum list installed glibc Installed Packages glibc.i686 2.3.6-3 -- >Comment By: SourceForge Robot (sf-robot) Date: 2007-02-20 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Jarek Zgoda (zgoda) Date: 2007-02-06 03:24 Message: Logged In: YES user_id=9 Originator: YES Thank you, will try my luck with MySQLdb. -- Comment By: Tim Peters (tim_one) Date: 2007-02-06 02:31 Message: Logged In: YES user_id=31435 Originator: NO Since the top 6 or 7 stack entries are all in /usr/lib/mysql/libmysqlclient_r.so.14, and shows it trying to using its own free() function (my_no_flags_free()), it's almost certainly a problem in the extension module (as opposed to in Python). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653121&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
