Changes by Alan Hourihane :
--
resolution: accepted -> remind
___
Python tracker
<http://bugs.python.org/issue10898>
___
___
Python-bugs-list mailing list
Un
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 ->
Alan Hourihane added the comment:
No, that patch still doesn't work.
--
resolution: fixed -> accepted
___
Python tracker
<http://bugs.python.org
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.pyt
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.o
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
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.
--
___
Py
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
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
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/is
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.
--
keyw
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/f
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
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 a
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-
Alan Hourihane added the comment:
Anyone ?
--
resolution: -> remind
___
Python tracker
<http://bugs.python.org/issue19346>
___
___
Python-bugs-list mai
Changes by Alan Hourihane :
--
resolution: -> remind
___
Python tracker
<http://bugs.python.org/issue19036>
___
___
Python-bugs-list mailing list
Unsubscrib
Alan Hourihane added the comment:
Anyone ?
--
resolution: -> remind
___
Python tracker
<http://bugs.python.org/issue19348>
___
___
Python-bugs-list mai
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
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.
--
___
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
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
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/i
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 +
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.
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/is
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.
--
c
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/is
Alan Hourihane added the comment:
As mention in the versions. It is Python 3.3.0.
--
___
Python tracker
<http://bugs.python.org/issue17237>
___
___
Python-bug
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=0x3
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
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/is
Alan Hourihane added the comment:
Bumping. How does Jeffrey's patch look folks ?
--
___
Python tracker
<http://bugs.python.org/issue17226>
___
___
Pytho
33 matches
Mail list logo
