[issue10898] posixmodule.c redefines FSTAT
Changes by Alan Hourihane : -- resolution: accepted -> remind ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: Hi Antoine, Unfortunately the #undef is too early and later #includes redefine it. We should move the #undef closer to the code that actually uses them. -- resolution: fixed -> accepted status: closed -> open ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: No, that patch still doesn't work. -- resolution: fixed -> accepted ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: I've had to split the three #undef's up to just before they're used. -- ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: Well, I'd probably prefer something akin to my first patch then. There's no need to #undef things at all if we just prefix the usage with PYTHON_ -- ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
New submission from Alan Hourihane :
Python 2.7.1 redefines FSTAT, but the problem is my libc already defines FSTAT
in sys/ioctl.h.
I've worked around this by prefixing the FSTAT define with PYTHON. It should
probably be done with STAT too.
--- Modules/posixmodule.c.old 2011-01-12 01:46:45.0 +
+++ Modules/posixmodule.c 2011-01-12 01:47:05.0 +
@@ -344,11 +344,11 @@
#undef STAT
#if defined(MS_WIN64) || defined(MS_WINDOWS)
# define STAT win32_stat
-# define FSTAT win32_fstat
+# define PYTHON_FSTAT win32_fstat
# define STRUCT_STAT struct win32_stat
#else
# define STAT stat
-# define FSTAT fstat
+# define PYTHON_FSTAT fstat
# define STRUCT_STAT struct stat
#endif
@@ -6641,7 +6641,7 @@
if (!_PyVerify_fd(fd))
return posix_error();
Py_BEGIN_ALLOW_THREADS
-res = FSTAT(fd, &st);
+res = PYTHON_FSTAT(fd, &st);
Py_END_ALLOW_THREADS
if (res != 0) {
#ifdef MS_WINDOWS
--
messages: 126120
nosy: alanh
priority: normal
severity: normal
status: open
title: posixmodule.c redefines FSTAT
type: compile error
___
Python tracker
<http://bugs.python.org/issue10898>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10898] posixmodule.c redefines FSTAT
Alan Hourihane added the comment: On Tue, 2011-01-18 at 19:59 +, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > How about adding "#undef FSTAT" instead? Would it work for you? Sure. Alan. -- ___ Python tracker <http://bugs.python.org/issue10898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
Alan Hourihane added the comment: This works for me... --- configure.ac.old2013-09-10 14:37:20.0 + +++ configure.ac2013-09-10 14:56:27.0 + @@ -2190,7 +2190,11 @@ AC_CHECK_LIB(intl, textdomain, [AC_DEFINE(WITH_LIBINTL, 1, [Define to 1 if libintl is needed for locale functions.]) -LIBS="-lintl $LIBS"]) +LIBS="-lintl $LIBS"], + [AC_SEARCH_LIBS(textdomain, intl, + [AC_DEFINE(WITH_LIBINTL, 1, + [Define to 1 if libintl is needed for locale functions.]) + LIBS="-lintl -liconv $LIBS"], , "-liconv")]) # checks for system dependent C++ extensions support case "$ac_sys_system" in -- ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check.
New submission from Alan Hourihane: Patch --- Python/fileutils.c.old 2013-09-11 07:04:42.0 + +++ Python/fileutils.c 2013-09-11 07:05:01.0 + @@ -4,8 +4,8 @@ # include #endif -#ifdef HAVE_LANGINFO_H #include +#ifdef HAVE_LANGINFO_H #include #endif -- components: Build messages: 197914 nosy: alanh priority: normal severity: normal status: open title: setlocale fails due to locale.h being wrapped up in LANGINFO check. versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue19036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check.
Alan Hourihane added the comment: Oops, meant to say. In pythonrun.c the setlocale() call is already wrapped inside the #ifdef so the problem ISN'T bumped into there. -- ___ Python tracker <http://bugs.python.org/issue19036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check.
Alan Hourihane added the comment: Yes, it's a "Build" issue as mentioned using the "Components" field. But cut & pasting from other files is incorrect in this case because setlocale() is still used outside of the #ifdef. File attached. -- keywords: +patch Added file: http://bugs.python.org/file31801/python-3.3.2.patch ___ Python tracker <http://bugs.python.org/issue19036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check.
Alan Hourihane added the comment: You'll see the error on any platform that doesn't include "locale.h" when it should, i.e. a platform that doesn't have NL_LANGINFO. This is the build error. Python/fileutils.c: In function 'check_force_ascii': Python/fileutils.c:101:5: warning: implicit declaration of function 'setlocale' [-Wimplicit-function-declaration] Python/fileutils.c:101:21: error: 'LC_CTYPE' undeclared (first use in this function) Python/fileutils.c:101:21: note: each undeclared identifier is reported only once for each function it appears in You can simulate it on Linux, by just commenting out the #include for "locale.h" and voila. But for completeness, it's an m68k Atari platform. -- ___ Python tracker <http://bugs.python.org/issue19036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check.
Alan Hourihane added the comment: Sure, Look in the function. check_force_ascii() You'll see a hunk of code that is ifdef'd for ... #if defined(HAVE_LANGINFO_H) && defined(CODESET) Then you'll see setlocale() is called outside of that check, just before another hunk of code is ifdef'd with the same #if defined(HAVE_LANGINFO_H) && defined(CODESET) Basically making setlocale() outside of the check, and therefore requiring the #include outside of the above check as well. In pythonrun.c the setlocale() call is already wrapped inside the #ifdef so the problem is bumped into there. -- ___ Python tracker <http://bugs.python.org/issue19036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19346] Build fails when there are no shared extensions to be built
New submission from Alan Hourihane: When building python with static extensions and therefore there are no shared extensions to be built the extension list can be NULL, and therefore 0 length. This results in this error running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers Traceback (most recent call last): File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/setup.py", line 2017, in main() File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/setup.py", line 2011, in main 'Lib/smtpd.py'] File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/core.py", line 152, in setup dist.run_commands() File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Lib/distutils/command/build_ext.py", line 339, in run self.build_extensions() File "/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/setup.py", line 266, in build_extensions longest = max([len(e.name) for e in self.extensions]) ValueError: max() arg is an empty sequence To fix I replaced this line in setup.py longest = max([len(e.name) for e in self.extensions]) to this... longest = 0 for e in self.extensions: longest = max(longest, len(e.name)) -- components: Build messages: 200922 nosy: alanh priority: normal severity: normal status: open title: Build fails when there are no shared extensions to be built type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue19346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19348] Building _testcapimodule as a builtin results in compile error
New submission from Alan Hourihane: When building _testcapimodule.c as a builtin module, the build fails with this error because it doesn't take into account Py_BUILD_CORE from datetime.h. m68k-atari-mint-gcc -I. -IInclude -I/j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Include -I/usr/include -fno-strict-aliasing -O2 -pipe -fwrapv -DNDEBUG -DPy_BUILD_CORE -c /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c -o Modules/_testcapimodule.o /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c: In function 'test_datetime_capi': /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1281:9: error: 'PyDateTimeAPI' undeclared (first use in this function) /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1281:9: note: each undeclared identifier is reported only once for each function it appears in /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1293:5: error: 'PyDateTime_IMPORT' undeclared (first use in this function) /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c: In function 'test_string_from_format': /j/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_testcapimodule.c:1444:5: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type 'int' [-Wformat] make: *** [Modules/_testcapimodule.o] Error 1 I fixed it by adding this around the datetime.h include in _testcapimodule.c but not sure if this is correct /* Differentiate between building the core module and building extension * modules. */ #ifdef Py_BUILD_CORE #undef Py_BUILD_CORE #include "datetime.h" #define Py_BUILD_CORE #else #include "datetime.h" #endif -- components: Build messages: 200926 nosy: alanh priority: normal severity: normal status: open title: Building _testcapimodule as a builtin results in compile error type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue19348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19346] Build fails when there are no shared extensions to be built
Alan Hourihane added the comment: Anyone ? -- resolution: -> remind ___ Python tracker <http://bugs.python.org/issue19346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check.
Changes by Alan Hourihane : -- resolution: -> remind ___ Python tracker <http://bugs.python.org/issue19036> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19348] Building _testcapimodule as a builtin results in compile error
Alan Hourihane added the comment: Anyone ? -- resolution: -> remind ___ Python tracker <http://bugs.python.org/issue19348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5865] mathmodule.c fails to compile due to missing math_log1p() function
New submission from Alan Hourihane : mathmodule.c fails to compile because math_log1p() is missing in mathmodule.c... gcc -fno-strict-aliasing -DNDEBUG -O2 -pipe -fomit-frame-pointer -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/mathmodule.c -o Modules/mathmodule.o ./Modules/mathmodule.c: In function 'math_log1p': ./Modules/mathmodule.c:353: error: 'log1p' undeclared (first use in this function) ./Modules/mathmodule.c:353: error: (Each undeclared identifier is reported only once ./Modules/mathmodule.c:353: error: for each function it appears in.) ./Modules/mathmodule.c: In function 'math_fsum': ./Modules/mathmodule.c:574: warning: passing argument 1 of 'PyFPE_dummy' discards qualifiers from pointer target type -- components: Extension Modules messages: 86733 nosy: alanh severity: normal status: open title: mathmodule.c fails to compile due to missing math_log1p() function versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5865> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5865] mathmodule.c fails to compile due to missing math_log1p() function
Alan Hourihane added the comment: I do have log1p() available... checking for log1p... yes And it's in math.h and libm.a on my system. I still can't see any reference to math_log1p() in mathmodule.c which is why it's barfing. -- ___ Python tracker <http://bugs.python.org/issue5865> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5865] mathmodule.c fails to compile due to missing math_log1p() function
Alan Hourihane added the comment: Ah. right. I see what you mean about the macro expansion. So I'm on an Atari FreeMiNT platform which is an m68k box which has no shared libraries so I'm setting up for static only via Setup.dist. Note that cmathmodule.c compiles fine and that does reference log1p() too. This is basic 2.6.2 from the tarball. -- ___ Python tracker <http://bugs.python.org/issue5865> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5865] mathmodule.c fails to compile due to missing math_log1p() function
Alan Hourihane added the comment: It's ok, I see what the problem is. It's GCC's headers that are causing trouble. Closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue5865> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5865] mathmodule.c fails to compile due to missing math_log1p() function
Alan Hourihane added the comment: GCC was munging math.h when it did fixincludes. I'm fixing the GCC port now. Result of 1e16+2.9 is... 10002.00 -- ___ Python tracker <http://bugs.python.org/issue5865> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
New submission from Alan Hourihane: The configure.ac script detects libintl but can depend on libiconv. I added this to force it and to demonstrate, but I think this is not 100% correct and should be massaged into the libintl tests. --- configure.ac.old2013-02-16 09:34:55.0 + +++ configure.ac2013-02-16 09:43:22.0 + @@ -2122,6 +2122,15 @@ # pthread (first!) on Linux fi +# Check iconv +AC_CHECK_LIB([iconv], [iconv_open], , [ac_found_iconf=no]) +if test "x$ac_found_iconf" = "xno"; then + AC_CHECK_LIB([iconv], [libiconv_open], , [ac_found_iconf=no]) +fi +if test "x$ac_found_iconf" = "xyes"; then + LIBS="-liconv $LIBS" +fi + # check if we need libintl for locale functions AC_CHECK_LIB(intl, textdomain, [AC_DEFINE(WITH_LIBINTL, 1, -- components: Build messages: 182327 nosy: alanh priority: normal severity: normal status: open title: libintl should also check for libiconv versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
Alan Hourihane added the comment: Hi Yes, when Python is built as static only, on a system when no dynamic loading is available. You have to explicitly link libiconv when libintl references it. -- ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
Alan Hourihane added the comment: Sure this is on an Atari m68k platform called FreeMiNT. Traditionally in configure scripts you'll see it checked as *-mint* -- ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
New submission from Alan Hourihane: On m68k this assert triggers in Python/unicodeobject.c:4658 because m68k architectures can align on 16bit boundaries. assert(!((size_t) dest & LONG_PTR_MASK)); I'm not sure of the wider implications in Python as to how to rectify. -- components: Build messages: 182381 nosy: alanh priority: normal severity: normal status: open title: m68k aligns on 16bit boundaries. versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Alan Hourihane added the comment: I'm willing to help fix, but there are m68k emulators out there which I guess suffice for a test box. -- ___ Python tracker <http://bugs.python.org/issue17237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Alan Hourihane added the comment: As mention in the versions. It is Python 3.3.0. -- ___ Python tracker <http://bugs.python.org/issue17237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Alan Hourihane added the comment: It must be about pointer alignment, because that's the whole point of the ASSERT. As for the backtrace, the gdb support on the platform isn't great yet, but here it is Breakpoint 1, ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", dest=0x1a6d592 "���") at Objects/unicodeobject.c:4658 4658assert(!((size_t) dest & LONG_PTR_MASK)); (gdb) bt #0 ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", dest=0x1a6d592 "���") at Objects/unicodeobject.c:4658 #1 0x030595a6 in .L4737 () at Objects/unicodeobject.c:4741 #2 0x03044dba in .L2648 () at Objects/unicodeobject.c:1806 #3 0x03096f54 in PyUnicode_InternFromString (cp=0x30c5b04 "__len__") at Objects/unicodeobject.c:14284 #4 0x030c69f6 in .L1892 () at Objects/typeobject.c:6090 #5 0x030c6dc8 in add_operators (type=0x33507c8) at Objects/typeobject.c:6244 #6 0x030bfc66 in .L1249 () at Objects/typeobject.c:4182 #7 0x030bfbae in .L1241 () at Objects/typeobject.c:4146 #8 0x02ff62a8 in _Py_ReadyTypes () at Objects/object.c:1576 #9 0x0300e688 in .L60 () at Python/pythonrun.c:301 #10 0x0300ea5c in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401 #11 0x0300ea6e in Py_Initialize () at Python/pythonrun.c:407 #12 0x02ff9fca in .L135 () at Modules/main.c:657 #13 0x02ff24be in .L6 () at ./Modules/python.c:90 #14 0x03329d5a in .L76 () #15 0x0331731e in .L69 () -- ___ Python tracker <http://bugs.python.org/issue17237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Alan Hourihane added the comment: It's GCC 4.6.3. GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used. -- components: +Build -Unicode type: crash -> versions: -Python 3.4 ___ Python tracker <http://bugs.python.org/issue17237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Alan Hourihane added the comment: Oh, and as for pointer alignment, I probably just wasn't clear in the initial report. But we agree on m68k C ABI. -- ___ Python tracker <http://bugs.python.org/issue17237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
Alan Hourihane added the comment: Bumping. How does Jeffrey's patch look folks ? -- ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
