[ python-Bugs-1563963 ] Typo in whatsnew/pep-342.html
Bugs item #1563963, was opened at 2006-09-23 13:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Xavier Bassery (balthus) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in whatsnew/pep-342.html Initial Comment: In http://docs.python.org/whatsnew/pep-342.html the following a word is missing in the following excerpt: "Because yield will often be returning None, you should always check for this case. Don't just use its value in expressions unless you're sure that the send() method will be the only method used *$$* resume your generator function." My guess is that "to" would be a good candidate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error
Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034
[ python-Bugs-1563185 ] ,msi fails for AMD Turion 64 mobile
Bugs item #1563185, was opened at 2006-09-22 00:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563185&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: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: ,msi fails for AMD Turion 64 mobile Initial Comment: I tried to install python-2.5.amd64.msi on my HP notebook with an AMD Turion 64 Mobile and I got the error message "This installation is not supported by this processor type." Is this really different than some other AMD 64, or do you just fail to recognize the ID? -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 13:18 Message: Logged In: YES user_id=21627 You should download the 32-bit installer, not the 64-bit installer, as you apparently run a 32-bit operating system (on your dual-mode 32/64-bit processor). The AMD64 MSI file can work only on a 64-bit operating system. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563185&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-23 00:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 13:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563981 ] IDLE invokes completion even when running code
Bugs item #1563981, was opened at 2006-09-23 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563981&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE invokes completion even when running code Initial Comment: When you do raw_input() A instead of putting the tab character into the input buffer, IDLE opens the completion window. It should not do this, since the user is interacting with its application, not with the Python interpreter at this point. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563981&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-23 01:17 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: Python Library Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 14:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error
Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 103
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-23 00:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: Python Library Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 14:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 13:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 13:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error
Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034
[ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error
Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 103
[ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX]
Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&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: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=21627 Skip, your problem is completely independent of the problem reported here. It rather has to do with the way Sun non-C89 API. -- Comment By: Skip Montanaro (montanaro) Date: 2006-09-12 22:01 Message: Logged In: YES user_id=44345 I'm coming late to this party (it seems the bar is closed), however... At work we just stumbled upon a similar problem when trying to build the latest release of matplotlib (0.87.5, avaialble at http://matplotlib.sourceforge.net/) on Solaris 10 using gcc 3.4.1. We get errors like the following: In file included from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/bits/postypes.h:46, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iosfwd:50, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ios:44, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ostream:45, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iostream:45, from swig/agg_buffer.h:7, from src/agg.cxx:1584: /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:145: error: `::btowc' has not been declared /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:150: error: `::fwide' has not been declared If I add #include at the top of Python.h it builds fine (modulo a couple warnings). One warning which might be significant is: In file included from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:10, from src/agg.cxx:97: /opt/app/g++lib6/python-2.4/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/wchar.h:11, from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:7, from src/agg.cxx:97: /usr/include/sys/feature_tests.h:266:1: warning: this is the location of the previous definition I don't have enough gcc smarts to understand what's happening, or even if it's the same problem Dimitri encountered on Solaris 8, but it kind of looks like the same sort of problem to me. Skip -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-03 22:34 Message: Logged In: YES user_id=21627 Thanks for the update. I believe nothing in the POSIX spec mandates to include unistd.h before anything else (unlike sys/types.h, which often is prerequisite to other headers), so I'm closing this report. ---
[ python-Bugs-1564039 ] 2.6 changes stomp on 2.5 docs
Bugs item #1564039, was opened at 2006-09-23 08:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&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: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: ggpauly (ggpauly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.6 changes stomp on 2.5 docs Initial Comment: Several links of the 2.5 changes index go to 2.6 changes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564039&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error
Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by djbclark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&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 Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 103
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-23 01:17 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 15:56 Message: Logged In: YES user_id=1067739 The actual code which broke used a Pointer extension class implemented in C++. I reproduced the problem using array.array. Using array in this way (without calling tostring) looks a bit weird. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 15:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 14:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562171 ] Fails to install on Fedora Core 5
Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Settings changed) made by mnsummerfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. -- Comment By: Mark Summerfield (mnsummerfield) Date: 2006-09-21 07:05 Message: Logged In: YES user_id=1602435 I didn't run out of disk space, I've 28GB free... I did try several times, (including make clean, rerun configure, make, make tests, and make install), and yes, it always failed in the same place. And just to make really sure, I have just tried the whole process again. I deleted my Python-2.5 directory, unpacked the whole thing again, ran configure, added -fwrapv to the Makefile, and ran make and make test. This time make test had only one "unexpected" skipped test: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 283 tests OK. 36 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 1 skip unexpected on linux2: test_bsddb Next I ran make install... and it worked! Maybe there's some dependency on having a dbm of some sort? Anyway, sorry for the false alarm. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 17:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562171 ] Fails to install on Fedora Core 5
Bugs item #1562171, was opened at 2006-09-20 12:33 Message generated for change (Settings changed) made by mnsummerfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&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: Installation Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Summerfield (mnsummerfield) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to install on Fedora Core 5 Initial Comment: I am using an up-to-date version of Fedora Core 5. : gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) configure I ran ./configure --prefix=/home/mark/opt/python25 and this ran without problems. Makefile I hand edited the Makefile to add -fwrapv to the BASECFLAGS as per the README file since I don't know how to add flags using configure. make make worked fine make test This reported some failures, but nothing that seems significant: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 281 tests OK. 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 3 skips unexpected on linux2: test_dbm test_gdbm test_bsddb make install This failed. ... Compiling /home/mark/opt/python25/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 Just in case for some reason a dbm is needed I installed gdbm-devel and retried but the installation still failed in the same place. -- Comment By: Mark Summerfield (mnsummerfield) Date: 2006-09-21 07:05 Message: Logged In: YES user_id=1602435 I didn't run out of disk space, I've 28GB free... I did try several times, (including make clean, rerun configure, make, make tests, and make install), and yes, it always failed in the same place. And just to make really sure, I have just tried the whole process again. I deleted my Python-2.5 directory, unpacked the whole thing again, ran configure, added -fwrapv to the Makefile, and ran make and make test. This time make test had only one "unexpected" skipped test: ... test_zipfile test_zipfile64 test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run test_zipimport test_zlib 283 tests OK. 36 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_sunaudiodev test_timeout test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 1 skip unexpected on linux2: test_bsddb Next I ran make install... and it worked! Maybe there's some dependency on having a dbm of some sort? Anyway, sorry for the false alarm. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-20 17:53 Message: Logged In: YES user_id=33168 This seems weird. Did you run out of disk space? Is the error reproducible (ie, fail in the same place each time)? Can you debug this further? The tests do a make install and I don't recall seeing this error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562171&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-23 01:17 Message generated for change (Comment added) made by adalx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 15:57 Message: Logged In: YES user_id=1067739 test_struct_run.py works in 2.4, throws exception in 2.5 -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 15:56 Message: Logged In: YES user_id=1067739 The actual code which broke used a Pointer extension class implemented in C++. I reproduced the problem using array.array. Using array in this way (without calling tostring) looks a bit weird. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 15:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 14:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 14:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563963 ] Typo in whatsnew/pep-342.html
Bugs item #1563963, was opened at 2006-09-23 04:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&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: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Xavier Bassery (balthus) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo in whatsnew/pep-342.html Initial Comment: In http://docs.python.org/whatsnew/pep-342.html the following a word is missing in the following excerpt: "Because yield will often be returning None, you should always check for this case. Don't just use its value in expressions unless you're sure that the send() method will be the only method used *$$* resume your generator function." My guess is that "to" would be a good candidate. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-23 11:12 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51988. 2.5 Committed revision 51989. head -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk
Bugs item #1563046, was opened at 2006-09-21 19:55
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: MacPython ignores user-installed Tcl/Tk
Initial Comment:
MacPython ignores any user-installed Framework Tcl/Tk. This is a
significant issue for Tcl/Tk users because the Tcl/Tk included with
Tiger is buggy and really shouldn't be used.
Bob Ippolito supplied me a recipe to fix _tkinter.so:
install_name_tool \
-change /System/Library/Frameworks/Tcl.framework/Versions/8.4/
Tcl \
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \
-change /System/Library/Frameworks/Tk.framework/Versions/8.4/
Tk \
/Library/Frameworks/Tk.framework/Versions/8.4/Tk \
_tkinter.so
I encapsulated this recipe into the attached python script "fixtkinter.py",
which modifies _tkinter.so to use the user's Tcl/Tk, if found.
Please consider running this script while installing MacPython. If you
want any refinements to the script, I am happy to provide them (or feel
free to modify it yourself of course).
Subtleties:
- The script uses Carbon.Folder.FSFindFolder to find the "/Library/
Framework" directory, so it should work in any country.
- The script fixes the _tkinter.so for the python that executes the script
(finding it relative to the "os" module).
- The script silently exits without doing anything if no /Library/
Framework Tcl/Tk is found. Thus it is safe to run for all MacPython
installations.
- It can safely be run more than once; it silently does not modify
_tkinter.so file the second time.
- It finds the link using ...Tcl.Framework/Versions/Current but resolves
the link before modifying _tkinter.so. So if a user upgrades a major Tcl/
Tk version the _tkinter.so file will keep using the old version. I think this
is a good thing, since compatilibility is likely to be an issue.
- It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it
does NOT look in the user's private library (~/Library). This was
intentional, but I'm not sure it was the right decision. I'm happy to
change it, but will want some advice on the best algorithm.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-23 20:52
Message:
Logged In: YES
user_id=580910
If this gets used (and that's a big if at the moment) it should not look in the
users private library folder, because the system might be used by multiple
users and a system wide install should not use files that happen to be in the
home directory of one of them.
I don't like using this script during installation but would prefer a slightly
different solution: ship this script in /Applications/MacPython 2.5 and tell
users about it in our documentation (the installer documentation, the
pythonmac.org FAQ and possibly the tkinter docs).
If Tiger's copy of Tk is really bad enough to avoid using it completely we
should find a way to ship a minimal copy of Tcl/Tk with our installer
(installed
into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/
{Tcl,Tk}.framework), again with your script installed in the applications
folder
for people that want to use a bleeding edge copy of Tk.
I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks
because of the support issue this raises: it is hard enough to debug problems
as it is without users haveing slightly different library versions.
BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, /
Library/Frameworks is named like that in all languages, the name you see in
the Finder might be different but that's because the Finder localizes the
names of a number of folders (hence the ".localized" file in a number of
folders).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563046 ] MacPython ignores user-installed Tcl/Tk
Bugs item #1563046, was opened at 2006-09-21 19:55
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython ignores user-installed Tcl/Tk
Initial Comment:
MacPython ignores any user-installed Framework Tcl/Tk. This is a
significant issue for Tcl/Tk users because the Tcl/Tk included with
Tiger is buggy and really shouldn't be used.
Bob Ippolito supplied me a recipe to fix _tkinter.so:
install_name_tool \
-change /System/Library/Frameworks/Tcl.framework/Versions/8.4/
Tcl \
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \
-change /System/Library/Frameworks/Tk.framework/Versions/8.4/
Tk \
/Library/Frameworks/Tk.framework/Versions/8.4/Tk \
_tkinter.so
I encapsulated this recipe into the attached python script "fixtkinter.py",
which modifies _tkinter.so to use the user's Tcl/Tk, if found.
Please consider running this script while installing MacPython. If you
want any refinements to the script, I am happy to provide them (or feel
free to modify it yourself of course).
Subtleties:
- The script uses Carbon.Folder.FSFindFolder to find the "/Library/
Framework" directory, so it should work in any country.
- The script fixes the _tkinter.so for the python that executes the script
(finding it relative to the "os" module).
- The script silently exits without doing anything if no /Library/
Framework Tcl/Tk is found. Thus it is safe to run for all MacPython
installations.
- It can safely be run more than once; it silently does not modify
_tkinter.so file the second time.
- It finds the link using ...Tcl.Framework/Versions/Current but resolves
the link before modifying _tkinter.so. So if a user upgrades a major Tcl/
Tk version the _tkinter.so file will keep using the old version. I think this
is a good thing, since compatilibility is likely to be an issue.
- It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it
does NOT look in the user's private library (~/Library). This was
intentional, but I'm not sure it was the right decision. I'm happy to
change it, but will want some advice on the best algorithm.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-23 20:52
Message:
Logged In: YES
user_id=580910
If this gets used (and that's a big if at the moment) it should not look in the
users private library folder, because the system might be used by multiple
users and a system wide install should not use files that happen to be in the
home directory of one of them.
I don't like using this script during installation but would prefer a slightly
different solution: ship this script in /Applications/MacPython 2.5 and tell
users about it in our documentation (the installer documentation, the
pythonmac.org FAQ and possibly the tkinter docs).
If Tiger's copy of Tk is really bad enough to avoid using it completely we
should find a way to ship a minimal copy of Tcl/Tk with our installer
(installed
into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/
{Tcl,Tk}.framework), again with your script installed in the applications
folder
for people that want to use a bleeding edge copy of Tk.
I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks
because of the support issue this raises: it is hard enough to debug problems
as it is without users haveing slightly different library versions.
BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, /
Library/Frameworks is named like that in all languages, the name you see in
the Finder might be different but that's because the Finder localizes the
names of a number of folders (hence the ".localized" file in a number of
folders).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
