[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-26 01:31
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 build fails on OpenBSD 3.7
Initial Comment:
Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice).
I'm including the logs here because they are short.
"./configure" printed the following:
checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be
compiled
configure: WARNING: curses.h: check for missing
prerequisite headers?
configure: WARNING: curses.h: see the Autoconf
documentation
configure: WARNING: curses.h: section "Present But
Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the
preprocessor's result
configure: WARNING: curses.h: in the future, the
compiler will take precedence
configure: WARNING: ##
##
configure: WARNING: ## Report this to
http://www.python.org/python-bugs ##
configure: WARNING: ##
##
checking for curses.h... yes
This warning was printed for curses.h, ncurses.h,
sys/audioio.h, and sys/lock.h. (The reference to
"Autoconf documentation" is useless, because autoconf
is not used during the configure process, and is not
even installed on the system where I was doing the
build.) Then:
% make
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include
-DPy_BUILD_CORE -o Modules/python.o Modules/python.c
In file included from /usr/include/sys/select.h:38,
from Include/pyport.h:116,
from Include/Python.h:55,
from Modules/python.c:3:
/usr/include/sys/event.h:53: error: syntax error before
"u_int"
/usr/include/sys/event.h:55: error: syntax error before
"u_short"
*** Error code 1
Stop in /usr/src/Python-2.4.1.
--
>Comment By: Hye-Shik Chang (perky)
Date: 2005-08-28 17:10
Message:
Logged In: YES
user_id=55188
For curses.h problem, it doesn't harm the build much in
fact. It's already reported to FreeBSD bugdb
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think
it's identical problem on OpenBSD.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-10 03:40
Message:
Logged In: YES
user_id=21627
Can somebody attach a config.log, or reproduce the fragment
that deals with the curses.h presence?
Does your system require any headers to be included for
curses.h to be usable? I.e. if you do
#include
int main(){}
will that program compile, or do you need additional
('prerequisite') headers?
--
Comment By: johnnie pittman (jp3g)
Date: 2005-08-09 15:34
Message:
Logged In: YES
user_id=1203137
Hey folks,
Also seeing this issue on 3.7. Same setup described above.
Loewis, not sure about the first part of your comment. If
your asking if those header files exist and are available,
yes they are (atleast on my system).
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-06 21:43
Message:
Logged In: YES
user_id=21627
So can you tell us whether there are missing prerequisite
headers? One would need to have access to your operating
system to resolve this issue.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1258986 ] Makefile ignores $CPPFLAGS
Bugs item #1258986, was opened at 2005-08-14 22:11 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258986&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.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Dirk Pirschel (pirschel) Assigned to: Nobody/Anonymous (nobody) Summary: Makefile ignores $CPPFLAGS Initial Comment: Makefile ignores $CPPFLAGS Environment variable. Solution: patch Makefile.pre.in with - snip - 59c59 < CPPFLAGS= -I. -I$(srcdir)/Include --- > CPPFLAGS= -I. -I$(srcdir)/Include @CPPFLAGS@ - snip - -- >Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 17:15 Message: Logged In: YES user_id=55188 It's already fixed in revision 1.149. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1258986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-864374 ] 2.3.3 tests on cygwin
Bugs item #864374, was opened at 2003-12-22 13:30 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.3 tests on cygwin Initial Comment: Hello, After running ./configure --prefix=/usr make make test I get the following --- 217 tests OK. 7 tests failed: test_bz2 test_fork1 test_largefile test_os test_popen2 test_pty test_tempfile 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on cygwin. When running test_bz2, test_fork1, test_popen2, test_pty, test_tempfile alone they look ok (return value to OS is 0). For the others I'm attaching output. My system is win2k on IBM T30 (laptop). Cygwin 1.5.5. Miki -- >Comment By: Miki Tebeka (tebeka) Date: 2005-08-28 14:02 Message: Logged In: YES user_id=358087 Sorry, due to some bizzar DLL relocation problems with cygwin I can't run the rull test suite. However test_bz2 fails *before* the test suite gets stuck -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 16:28 Message: Logged In: YES user_id=1188172 Can you verify this with 2.4.1 or a CVS version? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234674 ] filecmp.cmp's "shallow" option
Bugs item #1234674, was opened at 2005-07-08 11:01 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mendez (goatsofmendez) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-28 22:24 Message: Logged In: YES user_id=1307917 The cache is buggy too; it can be fooled by changing the cwd between calls. Also, if it caches (a, b) it does not cache (b, a). Is this caching feature really useful? Maybe it's up to the caller to record what comparisons have been made. If a caching function is to be provided, it should recognize the (b, a) case and maybe also infer from (a, b) and (b, c) about (a, c). (My programs remember an md5-signature) I propose to eliminate the caching feature. Also I propose to publish cmp_shallow and cmp_bytes which I think will make the unit easier to understand and verify. cmp_bytes is of course _do_cmp, with a check added for length equality. Then, the docs should be updated to whatever implementation for cmp is chosen, because non-shallow comparison is ill-specified. cmp should return a bool. what should cmp do with funny input like a dir? It now returns false. Would an exception be better? BTW: is it really useful in _do_cmp to have a local variable bufsize? is 8k still optimal? -- Comment By: Mendez (goatsofmendez) Date: 2005-08-26 13:38 Message: Logged In: YES user_id=1309441 On my own system I've modified the testing code as follows if s1 != s2: return False if shallow and s1 == s2: return True Which works as I expected it to work If attributes aren't identical - Always fails If the attributes are identical and it's in shallow mode - returns true If the attributes are identical and it's not in shallow mode - goes on to check if the files are byte identical. Whether there should be additional modes for finding byte identical files with different names, attributes etc. is another matter. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 10:33 Message: Logged In: YES user_id=80475 Fred, do you have thoughts on this patch? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234674 ] filecmp.cmp's "shallow" option
Bugs item #1234674, was opened at 2005-07-08 11:01 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234674&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mendez (goatsofmendez) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: filecmp.cmp's "shallow" option Initial Comment: The filecmp.cmp function has a shallow option (set as default) to only compare files based on stats rather than doing a bit by bit comparison of the file itself. The relevant bit of the code follows. s1 = _sig(os.stat(f1)) s2 = _sig(os.stat(f2)) if s1[0] != stat.S_IFREG or s2[0] != stat.S_IFREG: return False if shallow and s1 == s2: return True if s1[1] != s2[1]: return False result = _cache.get((f1, f2)) if result and (s1, s2) == result[:2]: return result[2] outcome = _do_cmp(f1, f2) _cache[f1, f2] = s1, s2, outcome return outcome There's a check to see if the shallow mode is enabled and if that's the case and the stats match it returns true but the test for returning false is for only one of the stats attributes meaning that it's possible for a file not to match either test and the function to carry on to the full file check lower down. The check above to see if the stats match with stat.S_IFREG also looks wrong to me, but it could just be I don't understand what he's trying to do :) This code is the same in both 2.3 and 2.4 -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-29 00:16 Message: Logged In: YES user_id=1307917 "cmp should return a bool" refers to the modules docstring. On other places, it does already. The default value for "shallow" should be a bool too. -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-28 22:24 Message: Logged In: YES user_id=1307917 The cache is buggy too; it can be fooled by changing the cwd between calls. Also, if it caches (a, b) it does not cache (b, a). Is this caching feature really useful? Maybe it's up to the caller to record what comparisons have been made. If a caching function is to be provided, it should recognize the (b, a) case and maybe also infer from (a, b) and (b, c) about (a, c). (My programs remember an md5-signature) I propose to eliminate the caching feature. Also I propose to publish cmp_shallow and cmp_bytes which I think will make the unit easier to understand and verify. cmp_bytes is of course _do_cmp, with a check added for length equality. Then, the docs should be updated to whatever implementation for cmp is chosen, because non-shallow comparison is ill-specified. cmp should return a bool. what should cmp do with funny input like a dir? It now returns false. Would an exception be better? BTW: is it really useful in _do_cmp to have a local variable bufsize? is 8k still optimal? -- Comment By: Mendez (goatsofmendez) Date: 2005-08-26 13:38 Message: Logged In: YES user_id=1309441 On my own system I've modified the testing code as follows if s1 != s2: return False if shallow and s1 == s2: return True Which works as I expected it to work If attributes aren't identical - Always fails If the attributes are identical and it's in shallow mode - returns true If the attributes are identical and it's not in shallow mode - goes on to check if the files are byte identical. Whether there should be additional modes for finding byte identical files with different names, attributes etc. is another matter. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 10:33 Message: Logged In: YES user_id=80475 Fred, do you have thoughts on this patch? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-26 10:19 Message: Logged In: YES user_id=1188172 Hm. Looks like if the size is identical, but the mtime is not, the file will be read even in shallow mode. The filecmp docs say "Unless shallow is given and is false, files with identical os.stat() signatures are taken to be equal." The filecmp.cmp docstring says "shallow: Just check stat signature (do not read the files)" Two questions arise: - Should the file contents be compared in shallow mode if the mtimes do not match? - Should the mtimes matter in non-shallow mode? -- You can respond by visiting: https://sourceforge.net
